Why aren’t user stories estimated in hours or days?
Because, in complex environments, it simply doesn’t work.
In traditional project management, people attempt to estimate how long something will take and how much that will cost.
That’s ok in a simple or complicated environment, because you’ve probably built hundreds of bridges and have a fair idea of how long each segment will take, who is best positioned to do that work, and how long that will take.
But in a complex environment, you’ve never solved the problem before nor has the solution ever been built, so you’re unsure whether you can solve the problem or build the product, let alone be able to estimate how long that will take.
There are too many unknown variables, and you can only discover and learn through doing, active experimentation, and will only know the answer once you have solved the problem or built the product.
There are several reasons why we don’t estimate in hours or days.
- It’s hard to estimate the unknown
- Defining time in terms of time elapsed or effort delivered
- Team evolution
It’s hard to estimate the unknown
Traditionally, we based estimates on past performances. So, if it took us a week to build X in the past, it seems reasonable to estimate a week to repeat that performance.
In a complex environment, we don’t know how long something takes because we have never built it before. We simply have no frame of reference for it and so we can estimate how much effort is involved or the level of difficulty, but we can’t estimate how long it will take.
The team may have a breakthrough and solve the problem within 30 minutes, or they may be stumped for weeks before any progress is made. They won’t know until they do the work.
Defining time in terms of time elapsed or effort delivered
In high-pressure environments, we often misunderstand or miscommunicate what we mean by the amount of time required.
I had an experience with a director where I was asked how long something would take, just an estimate, and I estimated it would take roughly 2 hours to complete.
The director was happy with that and off she went.
Two hours later she returned and asked for the item.
I had been in a meeting for the past 2 hours and so I had not had a chance to work on the item yet and wouldn’t be able to get to it for another few hours because of the commitments I had to meet first.
As you can imagine, she wasn’t impressed.
So, I can estimate that an item should take approximately X amount of time, but I can’t guarantee a delivery with an elapsed time.
The problem I am currently working on may take a few more hours than anticipated, and so the item that I will work on next may only take a couple of hours, but I’ll not be able to deliver it within an elapsed period that I estimate because I need to complete the current item first.
If you are only working on a couple of items, that isn’t a train smash, but when you have multiple items in a backlog, it becomes more problematic. You cannot estimate a delivery time reliably as there are too many variables involved.
As teams improve, they get better at solving X kinds of problems or building more complex products.
What used to take a month to deliver, now takes approximately a week, but in other areas we haven’t made as much progress, so it still takes a lot longer to deliver those items.
So, the team can still reliably estimate the complexity or difficulty of an item, but the time required to deliver that item could vary a great deal, especially as the team evolve in some areas but not as much in other areas.
If we used time estimates for items, we would constantly need to be updating the backlog with estimation of time to be delivered and it becomes a bit of a minefield to negotiate.
In agile, we don’t need to do that because the items are estimated in terms of effort, and that doesn’t change regardless of how well the team perform. It’s still difficult regardless of whether we can now solve that problem a day earlier than we used to.
So, these are some of the reasons why we don’t estimate in hours or days.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster