More Related Content
What's hot
What's hot (20)
Similar to The agile elephant in the room
Similar to The agile elephant in the room (20)
More from AgileDenver
More from AgileDenver (20)
Recently uploaded
Recently uploaded (20)
The agile elephant in the room
- 1. The Agile Elephant In The Room Mark Eastman Rocky Mountain Agile © 2017 Rocky Mountain Agile
- 2. Introduction © 2017 Rocky Mountain Agile • ME: • Enterprise Agile Coach • Founder Agile @ Scale SIG • Founder Rocky Mountain Agile • About you: • Name? Role? • Experience with Agile? • Expectations for the class? Mark Eastman
- 3. Introduction Two types of Agile Elephants 1. Hiding Elephants – very little info 2. Fighting Elephants – lots of contradictory info © 2017 Rocky Mountain Agile
- 4. Nonfunctional Requirements A Hiding Elephant © 2017 Rocky Mountain Agile
- 5. Nonfunctional Requirements Refresher Non-functional Requirements (NFRs) can be viewed as constraints that are applied to functional requirements. NFRs can come from just about anywhere: the PO, Architect, Development Team Example types of NFR’s • Portability • Usability • Maintainability • Availability • Scalability • Security • Compliance • Performance • Scalability Excellent article on NFRs from an Agile perpsective Nonfunctional Requirements Abstract (Scaled Agile) http://www.scaledagileframework.com/nonfunctional-requirements Functional Nonfunctional © 2017 Rocky Mountain Agile
- 6. User Stories Applied • 3 pages out of 268 cover NFRs • Essentially a reminder of what they are Scrum Guide • NFRs are not mentioned Essential Scrum • Half of a page out of 452 cover NFRs None of these tell you how to handle them! Some Popular References © 2017 Rocky Mountain Agile
- 7. NFRs do not belong in the PBL or any Sprint Backlog! NFR Tips © 2017 Rocky Mountain Agile We call User Stories Requirements, and they are… Functional Requirements NFRs are not Functional Requirements, therefore, do not treat NFRs as User Stories User Stories NFR’s Completed within one Sprint Can last the life of the product Developed Constrain development Estimated (pointed) Not estimated Direct user value Only indirect user value Prioritized by PO Prioritized by whole team
- 8. Where to Track NFRs US6: User can view shopping cart Acceptance Criteria 1. All items, quantities and prices show 2. Can remove items 3. Display takes .25 seconds or less under typical load, and 1 sec with max concurrent users Estimate: 5 © 2017 Rocky Mountain Agile Add them to your Acceptance Criteria
- 9. Where to Track NFRs Product Backlog Sprint BacklogNFRs © 2017 Rocky Mountain Agile Maintain them in your Backlog Tool
- 10. Where to Track NFRs Definition of Done (DoD) • Code checked in • Code reviewed • All tests passed • > 80% test coverage • navigation<= 3 mouse clicks • All passwords are here hashed © 2017 Rocky Mountain Agile Add them to your DoD
- 11. Where to Track NFRs Nonfunctional Requirements I Faster, faster, faster II Human friendly III Secure as a Fort Knox MMXVII © 2017 Rocky Mountain Agile Capture them in a separate specification
- 12. • All products/projects have NFRs • NFRs do not involve development, they constrain development • Do not treat NFRs as User Stories and don’t put them in any Backlog • Good places to track them: • Within Acceptance Criteria • In your backlog tool, separate from any Backlog • In your DoD • In their own spec NFR Summary © 2017 Rocky Mountain Agile
- 13. Technical Stories Fighting Elephants © 2017 Rocky Mountain Agile
- 14. What is a Technical Story? “A ‘user’ story (product backlog item) that delivers no perceived end-user value but does deliver important architecture or infrastructure needed to deliver future user value” - Innolution “A Technical User Story is one focused on non-functional support of a system” - Robert Galen “A technical story is an item of work in the Software Debt Backlog that pays off a chunk of debt that is understandable and valuable to the Product Owner” - Steve Smith “A User Story describes interaction between the system and an external entity. A Technical Story does not” - ME © 2017 Rocky Mountain Agile
- 15. Types of Technical Stories • Product Infrastructure • Standup production servers • Team Infrastructure • Standup continuous integration server • Standup QA environment • Architecture • Implement logging subsystem • Refactoring • Cleanup code in login subsystem • Spikes • Evaluate SQL Server vs Oracle • Refine requirements for PDF Reporting User Story Stand up an automated test environment © 2017 Rocky Mountain Agile
- 16. The Debate Assumptions • There is no argument about the work represented by Technical Stories – it needs to be done • The primary debate is really about Velocity. Should they be included in Velocity? For including in Velocity • We need to account for ‘all’ effort in our Velocity so it is accurate and we can forecast effectively • More dev team time under PO control Against including in Velocity • Agile is about providing User value, focusing on anything else is counterproductive • Many Technical Stories come from improper decomposition and should be part of a User Story • Technical Stories are nearly impossible for PO to prioritize © 2017 Rocky Mountain Agile
- 17. Include Them in Velocity? The Scenario – you’re having your house painted today • The painters plan to do 2 hours of prep followed by 6 hours of painting • It’s noon and they’ve prepped for 2 hours and painted for 2, just as planned © 2017 Rocky Mountain Agile You call the foreman to check status. Which is the best answer? 1) “We’re a third done” • He means 1/3 of the house is painted • 2 hours completed out of 6 hours of painting 2) “We’re half done” • He means they’ve completed 1/2 of the work planned for the day • 4 hours completed out of 8 hours of work See the difference? 1 ignores the prep work, 2 includes it They’re both correct!
- 18. First - Weed Out The Imposters Many Technical Stories are really Tasks that belong to a User Story These can result from poorly decomposed User Stories Examples: • Development Phases • Perform analysis • Develop xyz feature • Functional test for xyzp • Regression test • Architectural Layers • Develop database objects • Add logic for new alert in xyz Java class • Develop web GUI in JavaScript Update database tables Perform functional testing © 2017 Rocky Mountain Agile
- 19. Choose an Approach 1) Treat them like User Stories (include in Velocity) • Velocity will include a larger portion of the team’s effort (e.g., prep AND painting) • The PO will not be able to prioritize without the Dev Teams’ help 2) Handle them outside of the Backlog (do NOT include them in Velocity) • Velocity will only include PBIs with direct user value (e.g., only the painting) • Track them by creating a dummy PBI to contain them • Use Capacity Allocation to keep Velocity accurate • e.g., 20% of capacity on Technical Stories, 80% on User Stories • Allows the PO to manage how much effort it spent on Technical Stories vs. User Stories © 2017 Rocky Mountain Agile There is no wrong answer. Take the approach that works the best in your environment
- 20. Estimating an Entire Project A Hiding Elephant © 2017 Rocky Mountain Agile
- 21. How do I Estimate an Entire Project? © 2017 Rocky Mountain Agile
- 22. Definitions Epics • Take more than a quarter to complete Features • Must be able to complete in 1 planning increment (typically a quarter) User Stories • 2-5 days effort (for 2 week sprints) • Must be able to complete within a sprint Tasks • Optional • 4-8 hours effort © 2017 Rocky Mountain Agile Epic Feature Story Task Task Story Feature Story
- 23. 100 400 20 40 82 1 5 1 3 13 User Stories Features Epics Product Backlog We all know how to estimate these To estimate an entire project, we need to be able to estimate these © 2017 Rocky Mountain Agile
- 24. Pointing User Stories © 2017 Rocky Mountain Agile 1 5 1313
- 25. Pointing Features or Epics © 2017 Rocky Mountain Agile 1 2 313
- 26. Combining User Stories, Features and Epics For User Stories, we set Flip Flops to 1 For Features, we set a motorcycle to 1 How do we reconcile? Harley 1 Flip Flops 1 © 2017 Rocky Mountain Agile
- 27. Technique #1 - Extrapolate Compare a well understood large User Story to a well understood small Feature Use the Feature as your Anchor Story for remaining Features 13 400 ? © 2017 Rocky Mountain Agile Large User Story Small Feature
- 28. This technique can be useful, but is prone to cumulative error, especially for huge Epics What if there was a way to estimate even the largest Epic with no cumulative error? © 2017 Rocky Mountain Agile 13 ???
- 29. Technique #2 – Deep Narrow Dive Epics Features User Stories 1. Identify ALL Epics 2. Pick a well understood Epic and decompose it into ALL it’s constituent Features 3. Pick a well understood Feature and decompose it into ALL it’s constituent User Stories 4. Relatively estimate the User Stories 5. Total the points, round up to next Fibonacci number and assign the Parent Feature 6. Relatively estimate all the Features from the Parent Feature – use the Parent Feature as your Anchor Story 7. Total the points, round up to next Fibonacci number and assign the Parent Epic 8. Relatively estimate all the Epics - use the Parent Epic as your Anchor Story 9. Total all the Epics © 2017 Rocky Mountain Agile Parent Feature Parent Epic 1 3 5 13 3 3020 13080 300 300 1300 4000800 800 Total = 7500
- 30. Keys to success: • All Epics must be identified • All Features under the Parent Epic must be identified • All Stories under the Parent Feature must be identified • Do not decompose more than required • If it takes longer than a day to estimate a multi- million dollar project – you’re doing something wrong! © 2017 Rocky Mountain Agile This method is just as precise as any other We know this is true because it is as precise as it can be
- 31. Summary © 2017 Rocky Mountain Agile Seek input, do your research, then make the best decision for your situation. No one gets points for doing Agile We get points for exceeding our customer’s expectations Agile just happens to be the best tool we have today
- 32. Debriefing • What Elephants didn’t I cover? • Did you learn anything? • Did you have fun? © 2017 Rocky Mountain Agile
- 33. Additional Information Rocky Mountain Agile (will be online shortly) http://www.RockyMountainAgile.com Nonfunctional Requirements Abstract (Scaled Agile) http://www.scaledagileframework.com/nonfunctional-requirements Jefferies, Ron: Technical Stories: We don’t need ‘em http://ronjeffries.com/xprog/articles/technical-stories-we-dont-need-em/ The current Scrum Guide http://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100 Plainwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional © 2017 Rocky Mountain Agile Contact Info: Mark Eastman 303-881-4443 mark99@rocketworld.com
Editor's Notes
- Why don’t you ever see elephants hiding in trees? Because they're so good at it. Over the years, as a coach, I’ve seen teams run into a lot of common challenges. That’s expected. But for a portion of them, there was little if any common direction from the industry. From the flyer: There are many excellent courses, books and videos that can help you learn Agile and Scrum, but they all tend to ignore some common challenges teams run into. For example, non-functional requirements. How should we deal with them? Technical stories are also a big challenge. Good luck finding concrete, unbiased information on the pros and cons of the different approaches. Forecasting is another great example. How do you estimate or forecast an entire project? This session will cover a number of these “elephants” in the room and provide concrete and unbiased advise on how to deal with them. All recommendations are based on real-world experiences and will include an honest discussion of relevant pros and cons.
- I categorize NFRs as a hiding elephant since there is so little information available on how to deal with them in an Agile environment. Everything you’ve learned about NFRs applies when doing Agile. The only thing unique is how and where we track them.
- I’ve only found one source that provides any help in this area. Leffingwell, Dean Agile Software Requirements, page 348
- Note: usually do not use User Story Format, but you can if you want
- Add a NFR to Acceptance Criteria if the NFR only applies to a very few User Stories
- Using your Backlog Tool (e.g., JIRA, VersionOne, Rally) is fine, but make sure they are isolated from your PBL and Sprint Backlogs.
- Adding them to your DoD has the advantage of high visibility. It works best when you have a small number of NFRs. Otherwise the DoD will become to large to use as a DoD and review whenever a Story is completed
- Creating a separate NFR spec is the most common solution. Make sure to group NFRs into sections so folks can more easily find which ones might apply to there story.
- To cover Technical Stories fully would require at least a whole day. This presentation focuses on defining them and suggesting options for handling them
- My definition is important, not because it is more correct than the others, but because it drives the remaining slides
- Note: usually do not use User Story Format
- The most important thing is that the homeowner and the foreman are on the same page. If so, either answer can be correct.
- Don’t just delete the imposters. Find the User Story it is part of and add it as a task, adjusting the User Story’s points as needed.
- Do not demo them during the Sprint Review – they don’t have direct user value
- How many of us have been asked to estimate beyond a Sprint? AN entire project perhaps?
- Why max of 5 days effort for a User Story? That’s ½ a Sprint and leaves room for unkowns.
- Trivia – nearly all teams find that they are limited to either 8 or 13 point Stories for a Sprint
- Assign the flip flops a 1. Relatively estimate the rest
- Rank the items from lightest to heaviest . Pick an Anchor Story to equal 1 (i.e., the smallest item on the page). Then bucketize. To compare your estimates with reality: That model Harley is about 800 lbs VW bugs are about 2000lbs Mini Coopers are about = 3000lbs Duece ½ is about 13,000 lbs If the Harley = 1, anything in the neighborhood of Bug=2, Mini = 3, Duece ½ = 13 is great!
- If a Bicycle= 13 (25 lbs), a good estimate for the Harley (800 lbs) might be 40
- Really only useful if the largest item is within an order of magnitude of your largest story (e.g., largest story = 13, largest item should not be much larger than 130)
- Note: lighter shading implies less understanding User Stories total 25, so I rounded up to 30 Features totaled 260, so I rounded up to 300 When you need numbers larger than 100, multiply the modified Fibonacci sequence by 10, 100, 1000, etc. Note: For Features, I multiplied the modified Fibonacci numbers by 10 (e.g., 10, 20, 30, 50, 80, 130…) For Epics, I multiplied the modified Fibonacci numbers by 100 (e.g., 100, 200, 300, 500, 800, 1300…)