Bv Eng & Agile Specs For Scrum U.Key
2 likes544 views
1. Business value engineering (BVE) aims to continuously deliver more business value to customers through incremental improvements. It takes a learning approach focused on understanding customer needs. 2. Agile specifications provide just enough documentation for developers to implement user stories, typically being developed for one or a few user stories at a time. The content is determined by the team and improves over time based on feedback. 3. BVE and agile specifications work together when product owners work with stakeholders to develop specifications in sprints before stories, ensuring developers understand needs while avoiding unnecessary documentation. Continuous feedback improves the process.
![Definitions
BV Engineering is the values, principles and
practices that enable us to deliver more and
more Business Value [from a given team] as
we improve.
BVE: A learning and incremental improvement
approach to giving customers more of what
they really want, looking at the whole process,
end-to-end.
CSM v9.3 © Jeff Sutherland 1993-2008
2](https://image.slidesharecdn.com/bvengagilespecsforscrumu-key-091204152350-phpapp01/85/Bv-Eng-Agile-Specs-For-Scrum-U-Key-2-320.jpg)
![Joe Little, CST & MBA
Agile Coach & Trainer
20+ years in senior level consulting to well-known firms in New York,
London and Charlotte
Focus on delivery of Business Value
CST, CSP, CSM
Was Senior Manager in Big 6 consulting
Head of Kitty Hawk Consulting, Inc. since 1991
Head of LeanAgileTraining.com
Started trying to do [Agile] before reading The Mythical Man-Month
– http://agileconsortium.blogspot.com
– jhlittle@kittyhawkconsulting.com
© Joseph Little 2009
5](https://image.slidesharecdn.com/bvengagilespecsforscrumu-key-091204152350-phpapp01/85/Bv-Eng-Agile-Specs-For-Scrum-U-Key-5-320.jpg)
Bv Eng & Agile Specs For Scrum U.Key
- 1. BUSINESS VALUE ENGINEERING & AGILE SPECIFICATIONS ScrumU, December 4, 2009 © Joseph Little 2009 1
- 2. Definitions BV Engineering is the values, principles and practices that enable us to deliver more and more Business Value [from a given team] as we improve. BVE: A learning and incremental improvement approach to giving customers more of what they really want, looking at the whole process, end-to-end. CSM v9.3 © Jeff Sutherland 1993-2008 2
- 3. Definition Agile Specification: “Just enough” documentation developed for the implementors just in time. Not too much, not too little; just enough, in their opinion (and as results prove). Typically tied to one or a few User Stories. CSM v9.3 © Jeff Sutherland 1993-2008 3
- 4. Attributions Some people who directly or indirectly contributed: Ken Schwaber, Jeff Sutherland, Kent Beck, Peter Drucker, Takeuchi & Nonaka, Jim York, Chris Mats, Kent McDonald, Womack & Jones, Mary & Tom Poppendieck, Taiichi Ohno, some friends at “a large financial institution in Virginia”, and many others. CSM v9.3 © Jeff Sutherland 1993-2008 4
- 5. Joe Little, CST & MBA Agile Coach & Trainer 20+ years in senior level consulting to well-known firms in New York, London and Charlotte Focus on delivery of Business Value CST, CSP, CSM Was Senior Manager in Big 6 consulting Head of Kitty Hawk Consulting, Inc. since 1991 Head of LeanAgileTraining.com Started trying to do [Agile] before reading The Mythical Man-Month – http://agileconsortium.blogspot.com – jhlittle@kittyhawkconsulting.com © Joseph Little 2009 5
- 6. A Start “You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” Yogi Berra In other words: In my opinion, BV Engineering is the most important thing to work on.... © Joseph Little 2009 6
- 7. Some prerequisites You agree that... Our business is JIT knowledge creation Our business is JIT knowledge delivery Optimizing the Pareto Rule is key to success Customers don’t really know what they want “I know it when I see it.” What they really to act on is a complex set of trade-offs, including benefit, cost and time Tacit knowledge is more important than Explicit knowledge © Joseph Little 2009 7
- 8. What the Product Owner does BV Engineering Customers The Business External Customer facing people & The Team Internal Internal groups (Firm oriented) Content © Joseph Little 2008
- 9. First problem Customers want infinite features since effective cost to Dept is zero. This is not really how things “are”, but how most university departments are treated. (Universities really do not have infinite resources.) So, what to do? © Joseph Little 2009 9
- 10. “Ideal” solution We do cost benefit analysis in $, and any effort that gives less than 3X return does not get done. And efforts are ranked by their ratio. And any story that gets less than about 3X return does not get done. And, the senior manager gets real $ benefits and real $ costs, so she has an incentive to deploy early. BUT.... © Joseph Little 2009 10
- 11. Some solutions Make each Mgr estimate the benefits and have “the delphic 5” review the estimate vs other projects. Fix the time period. (“You can get any stories you want in 5 Sprints.”) The delphic 5 might do two rounds of guessing at the $ benefits of a project. And then avg. “Assume” that a project will deliver $ benefits that are 3X the costs. Give these projects to the delphic 5 for a “sniff test”. Probably for a few, they will say: “You must be kidding!” © Joseph Little 2009 11
- 12. Is it better this way? Customers The Business External Customer facing people & The Team Internal Internal groups (Firm oriented) Content © Joseph Little 2008
- 13. Hallmarks of real BV Engineering! 1. The process is visible and articulated & improved 2. Failures in BV communication are identified and corrected frequently, quickly 3. There is a theory, and a concerted attempt to prove out the theory 4. There is appropriate dynamism and change 5. Business & Technology are partners 6. Success is forecast and also measured after the fact 7. Human judgment is involved (it’s not just the numbers) © Joseph Little 2009 13
- 14. Agile Specifications So, one of the key things about BV Engineering is: How do we get the “requirements” into the Team, so they can do them the best? Agile Specifications are a partial answer © Joseph Little 2009 14
- 15. More assumptions We’re still doing lots of other stuff We’re still using User Stories and Acceptance Criteria The PO or another business person is having daily conversations with the Implementors (pigs). We developed “all” the stories as quickly as possible. Arch & Design were initially done using the User Stories (+ conversations, etc); and is continually being improved. We all actually believe in JIT knowledge creation Etc........ © Joseph Little 2009 15
- 16. Definition Agile Specification: “Just enough” documentation developed for the implementors just in time. Not too much, not too little; just enough, in their opinion (and as results prove). Typically tied to one or a few User Stories. CSM v9.3 © Jeff Sutherland 1993-2008 16
- 17. How do they work? One or two Sprints before a story goes into a Sprint, the PO arranges for the Agile Spec to be built. Maybe by the PO, the BA, a stakeholder The Team and the PO agree what will be in the Agile Spec. Maybe: Wire Frames, drawings, simple use case, data elements, key edit criteria, diagrams, pictures, more robust test examples, etc, etc. The Agile Spec enables conversation, it does not replace conversation. Based on experiences, the required content of the Agile Spec is continually being revised. © Joseph Little 2009 17
- 18. How again? How does the PO, BA, Stakeholder get the content for the Agile Spec? “Agile Spec” does not define that. There are many, many techniques. One best practice is to watch the real users carefully; interviewing user is by comparison fairly low value. Does the Pareto Rule apply to the content of the Agile Spec? YES!!! © Joseph Little 2009 18
- 19. How? (3) When exactly is an A.S. built? Not defined. Probably 1 or 2 Sprints before. Do the Implementors review the A.S. before the SPM? Yes!! Can the A.S. be tied to a specific User Story? Yes. What is the purpose? Probably many. One: To enable the implementors to get the PBI done as fast as possible (assuming also high quality). How do we know the content of the A.S. is right? The implementors keep giving the PO feedback. Continually improved. © Joseph Little 2009 19
- 20. Why? Why don’t you define the A.S. in more detail? Because what Team A needs is different than what Team B needs. Because: The following might be different: The product, the customers, the project, the environment, the PO (BA, stakeholder), the Team (memory, basic understandings, etc), etc, etc. We don’t build documentation around well-known knowledge We might need to document some knowledge that is not well known. © Joseph Little 2009 20
- 21. Documentation is ONLY there to support communication and understanding. © Joseph Little 2009 21
- 22. The End For now.... © Joseph Little 2009 22
- 23. Retrospective What do you remember? What will you act on tomorrow? What thing(s) will you do to improve your BV Engineering? © Joseph Little 2009 23