User Story Sizing using Agile Relative Estimation
17 likes
views
Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation. Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world! “It's better to be roughly right, than precisely wrong!” ~ John Maynard Keyenes The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck! PROBLEMS WITH TIME-BASED ESTIMATES -Teams spend too much time trying to get it right -Lack of confidence/experience can lead to people being either optimistic or pessimistic -Timeline you are estimating may be too far in the future -Due to long timeline, there are too many risks, unknowns, changes or dependencies! WHY USE RELATIVE ESTIMATION? -Allows a quick comparison of stories in the backlog -Allows you to select a predictable volume of work to do in a sprint -Uses a simple arbitrary scale -Allows PO to make trade-offs and take on the most valuable stories next ESTIMATION TIPS -Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile. -The team estimates the story, not management nor the customer. -Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues. -Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes. -Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready. -Only pull into your sprint, stories that are refined and estimated. -Break down stories that are large, into smaller slivers of value to optimize your flow. -Don’t sweat it if you get it wrong, teams often do early on but improve over time.
User Story Sizing using Agile Relative Estimation
- Story Sizing using Agile Relative Estimation Alex Kanaan
- About Me
- Connect with Me! Click Button For Direct Access More about Me http://www.alexkanaan.com Read My Blog http://www.alexkanaan.com/#latestnews Contact Me http://www.alexkanaan.com/#contact Follow my Tweets @AlexKanDu Connect on LinkedIn https://www.linkedin.com/in/arkanaan
- Let’s Get to Know You! • Waterfall Experience • Agile Experience • Beginners • Intermediate • Advanced • Scrum • Kanban • SAFe
- Question How long does it take 2 PM’s to change a lightbulb?
- Question How long does it take 2 PM’s to change a lightbulb? HINT: THINK!!!
- Question How long does it take 2 PM’s to change a lightbulb? Answer: Do you have a plan?
- Traditional Project Planning Creating a project plan is simple? Identify tasks, durations & dependencies Find out who will do the work & estimate how long it will take them to do it Plug all into MS Project and voila! So one person assigned to a task that takes 48 hours, will finish it in 6 days, right?
- Whoa...Whose Days Look like this?*
- Out-of-Time? So how many hours do you really have left to actually do the work in the plan?
- Planning for an 8 hour day? Assuming 8 hrs a day to allocate to tasks is not realistic!! What should we do?
- Problems with Traditional Estimates We spend too much time doing/redoing it But we rarely get it right - Fear of failure Lack of confidence/experience People are either pessimistic or optimistic Timeline may be too far into future Many unknowns, changes, dependencies
- Traditional Planning So how do we estimate accurately how long it will take to get things done?
- Traditional Planning So how do we estimate accurately how long it will take to get things done? Answer: You cannot!
- Self-Organize & Prove the Following! Fact: Humans stink at Estimating!
- So, Do Estimates Work?
- Traditional Planning “It is better to be roughly right... than precisely wrong” John Maynard Keynes
- Solution? Use Relative Estimation
- Relative Estimation Educated “finger-in-the-air” guess-timate that works!! Used in Product Backlog Uses comparing vs deconstructing Allows you to select a predictable volume of work to be done in a sprint Basis to do capacity based planning
- Sizing - Why Relative Estimation Uses a Simple Scale Normalized Story Points Quick Estimates - Sizing a story K.I.S.S. - Keeps it Simple It’s all relative - comparing & evaluating one story to another
- Sizing - Why Relative Estimation Allows PO to make tradeoffs Allows you to take on low hanging fruit first (more valuable stories)
- Let’s Get Started! Let’s learn how to use relative sizes for comparison
- How Much does a Terrier Weigh? (estimate)
- No Idea? Because we aren’t comparing it to anything...yet!
- So...Which Dog is Heavier?
- Where do we fit a Golden Retriever?
- Between Chihuahua & German Shepherd
- Let’s Up the Challenge! Lets use relative sizes to help us “fit” something new to our scale below
- Where do you fit a Terrier on the scale?
- More or Less than a German Shephard?
- Where on Scale?
- More or less than a Retriever?
- Where on Scale?
- More or less than a Chihuahua?
- Where on Scale?+
- About the same as a Chihuahua
- How Much Does a Terrier Weigh? HINT: This is what we know • Less than a German Shephard • Less than a retriever • About the same as a Chihuahua • But...we don’t know what a Chihuahua weighs Can You Answer NOW?
- What If You Had this Table?
- Can You Answer NOW?? (estimate) How much does a Terrier weigh?
- Yes…The Terrier Weighs... Roughly about the same as a Chihuahua, or 4-6 Ibs
- So how does this work in Agile? We create buckets of standard story sizes and ‘fit’ new stories in these buckets
- Do We Include Testing in Estimates?
- What About Deployment?
- YES: Include it ALL! ALL efforts in the process are included in the size estimate - including any spikes
- What is this? 1, 2, 3, 5, 8,13
- What is this? Modified Fibonacci Sequence 1, 2, 3, 5, 8,13 20, 40, 100, 200
- Size is not based on effort alone Unlike Waterfall, when we size stories, we do NOT base it on effort alone!
- More to Size than Effort alone! Story Point Size is based on at least Effort Complexity Doubt
- Effort Doubt Complexity Same Effort - Different Size 5PT Effor t D C 1PT Both stories have the same effort, why is the estimate so different?
- Effor t Doubt Complexit y Effor t Compl exity Doubt z Co mpl ex Dou bt Effort Different Efforts - Same Size 5PT 5PT5PT
- Using T-Shirt Sizing for your buckets Small 1pt Medium 2-3pt Large 5pt Extra Large 8 Points TOO BIG - Break into Smaller Stories
- Normalized Story Points • Pick a 1 pointer roughly equal 1 day • Agree with Team this is your one pointer in terms of effort, complexity and doubt • Compare new stories to it • Remember to use same scale within team
- Planning Poker Consent based estimation technique I don’t use it with my teams because I find developers are much more comfortable with giving a relative number rather than an exact number Mike Cohn’s Website for a good explanation
- Do we use hours in planning? Yes: In sprint planning where your planning horizon is only your 2-3 weeks - sprint length
- Remember the Mantra! Points for Stories, Hours for Tasks!
- Points for Stories, Hours for Tasks! Estimate Using When? For What? Stories Points Refinement Velocity Tasks Hours Sprint Planning Burndown Chart
- Tips on Sizing • Avoid confusion: Sizing vs Estimates • Use Story Points - choose & stick to scale • Break large stories to multiple small stories • Smaller stories have less uncertainty & easier to estimate more accurately • Only an estimate, don’t spend too much time • Team sizing efforts get better with time
- Relative Sizing Advantages • Sprint planning in minutes not hours! • Less Stress: Team doesn’t worry if estimates are not spot-on • Meeting sprint commitments starts to improve each sprint • We now have historical velocity that can be used towards future planning and accepting new projects
- Next Steps… If you liked my presentation, connect with me from the next page for more ☺
- Connect with Me! Click Button For Direct Access More about Me http://www.alexkanaan.com Read My Blog http://www.alexkanaan.com/#latestnews Contact Me http://www.alexkanaan.com/#contact Follow my Tweets @AlexKanDu Connect on LinkedIn https://www.linkedin.com/in/arkanaan