Mature agile estimation


Let's face it.... estimates are always going to be estimates! Not actuals.
No matter how much time we dedicate to getting the estimates "RIGHT", chances are they will still be wrong. They don't take into account the proverbial "unknown, unknowns" and in software development any item of work can contain unknowns or complexity that blow the estimates right out of the water!

In traditional project management the tendency is to chase reasons for "wrong" estimates and track actuals against estimates in some kind of attempt to get "better" at estimating. As a result, teams spend a lot of time putting hourly estimates on user stories, which still have a very high chance of being incorrect, so why bother? What a waste! Instead, spend a little bit of time estimating and be just as wrong/ right in the end!
I suggest a "mature" attitude to estimating. 
  • assume that the work will take as long as it takes
  • assume that everyone will do the best job they can on a user story
  • assume the team will not cut corners on quality
  • assume no unnecessary over-engineering
  • estimate "how big" user stories are using the fibonacci scale and comparatively estimate each story against other stories. (Is this bigger or smaller than the last one? How does it compare to our benchmark stories)
  • use the fibonacci scale because the gap between numbers increases as we go higher. This mimics software development in a way because the bigger the story, the higher the risk of unknowns or complexity creeping in which will increase the amount of time it takes to develop.
  • Based on the previous sprint's velocity, the current sprint's capacity and very importantly, gut feel. Project how much work the team can get done in the upcoming sprint
  • Use this projection to manage expectations of when you can deliver your features/ software/ product
  • If you "under-estimate", and have extra capacity left in a given sprint, then try to take extra stories into the sprint. (Pull system)
  • only take in additional stories if you can finish them by the end of the sprint otherwise you will affect your ability to be "potentially deployable" at the end of that sprint
Really, what management and product owners want to know is when we can deliver our products and they want predictability. The above method still gives us these things, but without the pain of hour estimation and actuals tracking.

Comments

Post a Comment

Popular posts from this blog

Things to consider when you want to change from Scrum to Kanban

Image
Scrum or Kanban? A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8% "Scrum doesn't work for us!" I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following: We can't finish anything in a 2 week sprint There are too many meetings Our list of priorities keeps changing We can't plan for 2 weeks.  Our product owner keeps changing his/her mind They often feel like Kanban is a silver bullet because: It doesn't ask you to finish anything in 2 weeks It doesn't im...
Read more

Expanded EPIC boards

Image
What's the problem? As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out. Additionally, defining an entire release worth of stories in advance which, ultimately, require change or m...
Read more

Moving beyond tasks

Image
One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks. Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees. How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on the...
Read more