Data skills for Agile Teams- Killing story points
- 1. You’ll understand why story points are astrology for software development Never have to waste your time again convincing developers to use points Or painfully explain to people in the business how points work Drop other outdated estimation techniques, charts & metrics Including your micro-managers favourite: Velocity And the infamous Burn-down chart You’ll know the alternative metrics to estimation Answering the business question of “when will I get this piece work?” All without signing the developers up for a death march You’ll also learn useful metrics to improve software delivery capability Without pissing off software developers Data skills for Agile teams: Killing story points! These are the outcomes :)
- 2. What’s the point on Story Points? What we saw to challenge story points Why estimating the work alone isn’t enough Thinking Probabilistically when Planning Getting the work into shape Learning & building key metrics Percentiles not averages ! Simulating a Sprint planning without story points Data skills for Agile teams: Killing story points! Agenda :)
- 3. Building shared understanding Better than hours Team ownership What’s the story on points?
- 4. Get into probabilistic mode Right size the work Agree on when we start & finish work Check List before data capture (You need to do these things before the next steps...)
- 5. Story points can be used to compare teams points per pound Points to get more, more, more! What’s the story on points?
- 6. Story point Conclusion Misuse is a problem Some tools are easier to abuse than others Time consuming when there are more optimal ways Confusion to learn & not useful for the business
- 7. “Are the 8's taking 8 times as long as the 1s?” “That don’t matter, it’s not about time, right?” “But surely, points give us an indication of relative size no?”
- 8. Discuss the item Select an item Vote Agree or disagree Work is given x value We keep an eye on how much we’re taking Once we hit our quota, we stop Discuss the item Select an item Can we do this work in 10 days or less? Agree or disagree If yes, bring the work in! If no, break it down We keep an eye on how much we’re taking Once we hit our quota, we stop Using story points in your planning meeting The alternative! Less time spent estimating Useful metrics to help the team improve More business friendly language More time spent estimating Less useful metrics to help the team improve Cryptic language hard for the business to understand
- 9. When will it be done? How much work can we get done in this sprint?
- 10. Do story points help us answer those questions? EFFORT COMPLEXITY SIZE Why is there such a low correlation between the 1's & the 8's? Surely, we’d see something 8 times, the effort, complexity, size... at least some items taking 8 times as long as the 1's?
- 11. When does it finish? When does work start? Cycle Time TO DO BUILD REVIEW DONE “Are the 8's taking 8 times as long as the 1s?”
- 13. TO DO BUILD REVIEW DONE “Our work ranges in size so much, we MUST have story points!” 8 points is so much bigger than 1 point, we can’t remove story points” Developer Bob Developer Lisa
- 15. Why do you think this is happening? Are the team really bad at estimating? Or are Story points not the best way to estimate? What could be behind this data? The lack of correlation?
- 16. If you wanted to figure out how long it would take to get to work.... would you make the estimation based on the amount of time your foot was on the gas pedal?
- 17. Many of us who live in busy cities know that getting from one point to the other, isn’t many miles but there is often a lot of things which get in your way! How often are you driving vs stopped wair
- 18. How could this metaphor relate to story points?
- 19. How likely is it for a developer to pick up a piece of work , focus on it with no disturbances, no delays, no blockers. To get it to the customer in one continuous flow, smoothly delivered?
- 20. How could this relate to story points?
- 21. When we use story points we are only thinking about the time, when the work is actively being done We appreciate and understand that story points do have conversations very often around, size, effort, complexity, risk… but Are you really asking when using points “ how long do we think this is going to be stuck with the devops team?” or “how long do we think the test environment is going to be down” - no one asks about this! Because we’re often focused on the work and not the system.
- 22. How long do you think a work item will spend actively being worked upon vs waiting in a queue? Discuss - based on your experience. Maybe you’ve measured, maybe you haven’t…
- 23. In our experience & the vast amount of industry data shows... Up to of the time is spent waiting!
- 24. Story points, least optimal idea. Story points, VERY bad idea. Story points are EVEN more risky for Large companies small company Big company WHY?
- 25. In really good teams ..... Around of the time is spent waiting!
- 26. Should we try to change that? Improve queue times? Yes... we want more to be spent doing the work vs waiting. TO DO BUILD REVIEW DONE
- 27. Sure we want to “fix the system” & get to the root cause as to why we have delays... ...but we also accept that it’s not a perfect world & not everything can be changed Do we want to measure what the team is capable of whilst taking into account the realities of imperfection?
- 31. Stacey Matrix
- 32. Holistic Cause & effect is NOT known Reductionistic Cause & effect is known
- 33. The two extremes of planning “OUR BIG PLAN TELLS US WHEN WE WILL DELIVER EVERYTHING “ “We’re light-weight & Agile, it will be done, when it’s done”
- 34. We need some idea of how long something is going to take because that’s how much it is going to cost “It will be done when its done” “ we think it’s likely to land here”
- 35. The alternative We need some idea of how long something is going to take DONE TO DO We can’t predict everything but we still need to manage expectation The work goes through the same system & if the system sucks it effects the ability of the work to travel through the system We need to work with probability not guarantee But what about the work itself? Is it in shape? Has it been created in a way which doesn’t add to the problems?
- 36. TO DO BUILD REVIEW DONE Is there anything we do to our work before we pull it in? ...to get it into better shape?
- 37. GETTING THE GETTING THE GETTING THE WORK INTO WORK INTO WORK INTO SHAPE SHAPE SHAPE
- 38. Getting the work into shape “how do you create work” “define units of value” “right sizing”
- 39. Your stories are sized to be within a range of time (“Can we get this done within 10 days or less?” Right sizing Right Sized not Same Sized (for example this does not mean all of your stories have be the same size) Too big, work on your board for months? Not great, transparency suffers (Hiding your work in progress), nothings getting to ‘Done’ is motivating! Longer it takes to get done…. Our learning is slower. Too big, you’re late on feedback. Too small, work which takes a couple of hours? Not great, now we have board with lots in progress at once, forcing team to break down work which doesn’t deliver significant value Work which is within an acceptable range (“Can I get this work done in 10 days or less?”)
- 40. Where possible slice work vertically You can slice work into workflow steps, business rules, happy/sad path, platform, type/parameters. operations, work by roles.
- 42. When does it finish? When does work start? Vital to agree on! This will dictate your metrics! TO DO BUILD REVIEW DONE
- 43. Get into probabilistic mode Right size the work Agree on when we start & finish work Check List before data capture (You need to do these things before the next steps...)
- 45. Get faster feedback from the customer Manage expectations -”When will I get this work ? Help the team improve how they work What metrics will help us ?
- 46. The data to capture The amount of elapsed time between when a work item started and when a work item finished. The full time includes queues, delays & all. Aging WIP: Cycle Time: Throughput: Throughput: The number of work items finished per unit of time. The amount of work done in a day, week, month etc. WIP: WIP means: Work in progress which is how many pieces of work have started but not finished. WIP Age is: Work Item Age, the total amount of time that has elapsed since an item entered a workflow. The time you have been on the road The number of cars that leave the road over a period of time The number of cars on the road The time it took to get to work (driving, delays, everything)
- 47. What is the problem with Story Points? What does the customer / stakeholder care about? Do story points help? How can we demonstrate this? Where does Software tend to sit on the Complexity scale? Therefore we need to think __________, not ____________ What checklist do we need to perform before getting into the metrics? What flow metrics should we start tracking?
- 48. Cycle Time Scatter Plot What is it? How to create it? How to use it?
- 49. When will it be done? One Work Item
- 50. Cycle Time Scatter Plot What are percentiles?
- 51. How do you communicate a date probabilistically?
- 52. A probability and a range e.g. we have an 85% chance of delivering 20 stories or less
- 53. How long will take for this work item to be done? Would you use an average? Juming out of plane, this will open 50% of the time would you be happy? If you use avg you’ll be right half the time and wrong half the time This is why we use percentiles! Say you have 100 dots when you get to 50 dots, that’s your 50% percentile.... 85% possibility work will get done in 18 days or less Percentiles not averages
- 54. WIP How to measure it? What to do with it?
- 55. Aging WIP How to create it? How to use it? Any extra info that could be useful here?
- 56. Aging WIP How to create it? How to use it?
- 57. If you focus on stopping work from aging you will fix all problems to do with flow
- 58. There are only two ways to stop work getting old Complete work or don’t start work (start less work!) Be very thoughtful about when we start work TO DO BUILD REVIEW DONE The team create an understanding that we want work to get done in 12 days The aim is to stop work from sitting on our board getting old
- 59. TO DO BUILD REVIEW DONE A lot of teams start work but may not have asked that question, “If i start this work at this point of the sprint can i get done within 12 days?” If there are known unknowns, can I get clarity before starting the work? If there are unknown, unknowns, wells there is little I can do about that! Perhaps a spike where possible?
- 60. When will it be done? Multiple Work Items
- 61. The team completed 12 stories last week We have 120 stories remaining When will it be done?
- 62. Plans made on average Fail on average
- 63. What are the odds of getting Heads? How do we know?
- 64. Forecast, and re-forecast often
- 67. Avg Cycle Time Avg Throughput = Littles Law Avg WIP
- 68. Consistent units must be used to measure Cycle Time, WIP, and Throughput All tasks entering the system will eventually exit the system once completed The average Arrival Rate is equal to the average Departure Rate There should not be large variances in WIP between the beginning and the end of the time period examined The WIP average age should remain the same, neither increasing nor decreasing Littles Law Assumptions
- 69. Littles Law Conditions for Stability Manage WIP Manage your Aging Work - the Aging WIP chart Key place to use this is in our daily stand ups: “what work is getting older?” Keep the team stable Agile principles for predictable teams Pull Policies - when do we start work? One of the most important influencers of team predictability If you get blocked? What do you do? Do you pick up a new item? Focus on e2e flow - getting things from start to finished Use data to continually assess how we are working Are our work items “right sized”? Is Cycle Time going up or down? WIP limits working for us? Aging WIP - what should we work on now? If you need to, Forecast and Re-Forecast often! Practical tips on how to help teams increase the certainty & likelihood of delivery in a complex world
- 70. Sprint Planning Discuss the item Select an item Vote Agree or disagree Work is given x value We keep an eye on how much we’re taking Once we hit our quota, we stop
- 71. Sprint Planning Discuss the item Select an item Can we do this work in 10 days or less? Agree or disagree If yes, bring the work in! If no, break it down We keep an eye on how much we’re taking Once we hit our quota, we stop
- 72. How do we get the quota? How much can we get done over a set period of time? Remember this is called throughput Let’s make it practical for those of us using something like Scrum or any team working over a set period of time (Iteration or Sprint) The sprint is the set period of time How much can we get done over a set period of time ? “How many work items do we get done per sprint, let’s use the 85 percentile”
- 73. What do we say to our managers? “We are taking in 30 points to complete this monthly sprint” We’re taking in 25 work items, we should have an 85% chance of completing them in the next 30 days” Story points: New age metrics:
- 75. DORA Metrics
- 78. stay in touch with us on LinkedIn & www.jemjelly.com Want to know more? Thanks! Jem & Terrence