Last week we had a heated team discussion as to when teams should estimate stories. Should it be once someone (the team BA) has completed his analysis and is passing the story over to those who will implement the story? Should it be once a high level design has been created (by a senior developer/architect)? And I do not want to open the discussion on formal hand-offs between roles within the team!
The argument for having estimation as soon as possible is that we get feedback on the effort required for changes before too much time has been expended. Versus waiting for the design to be completed and presented back to the team so that they are able to provide a more accurate estimate.
I felt that we were missing the point and should return to the basics, why we are estimating the size of the story to begin with? In my opinion the top three reasons to estimate are:
- Estimate how many stories the team can deliver. Using the team’s velocity, calculate when features will be delivered or how many stories can fit in the sprint?
- Select stories based upon their value vs effort, i.e. are lots of smaller stories delivering more value over all than a couple of larger stories?
- Uncover complexity and start discussions based on team members differing opinions/estimates/understanding.
You may have other thoughts, please let me know. However, I want to examine each of these below.
How much can be delivered?
In theory this sounds great. Given the estimated size of stories it should be possible to plan how much work can be done, or how much time is needed to complete the stories, taking into account the teams velocity.
But, it is important to remember that these are only estimates. We are working in a complex world, where new requirements/issues arise no matter how well you plan. Therefore, the estimate will not match how much time the team spend on the work - that is why it’s called an estimate.
If we are working in an agile way then we should periodically reflect on how we are delivering work. How often does this reflection include verifying deliver times to their estimates? Last year I took a look at our teams deliveries, plotting this graph of story points vs days to (dev) complete.
As you can see there is a trend that that larger stories took longer. However, this is only a weak trend. As you can see there are some 2-point stories taking longer than 3 and even most of the 5 point stories. There are tasks which were completed in 4 days which were estimated at 1, 3 and 5 points.
There are many reasons that the duration of tasks may vary, production incidents taking preference, too much WIP, etc. but this is not the place to discuss that. I just wanted to highlight that the estimates are just that - best guesses with the information known at the time.
Prioritise stories based on size vs value
Ideally, the Product Owner would be able to see a number of stories in the Product Backlog with their estimated size and be able to use this information to help them order the PBIs.
However, when the majority the team’s work has already been commited with dates, i.e. regulatory changes or senior managements per projects, then the estimate does not help the Product Owner prioritise work, that has already been done for them. Therefore, the estimate does not help with prioritisation, only to communicate the teams confidence in meeting deadlines.
As teams are often already overloaded, and these senior management stories have already been agreed before the the team are even aware of them. Therefore, by the time these stories are introduced by the BA it has already been decided that they need to be completed. Using complexity to prioritize work is in my view not relevant for our team.
Please note, I say that this is not relevant for our team. For others it will be. This is part of working Agile, using techniques which work for your team, and avoiding those that do not. Just be sure that you are reflecting often and changing your process as needed.
Uncover complexity
This, I believe is the primary reason for estimations - to uncover hidden complexity.
Once the team are familiar with story each team member should be able to make an informed estimate as to what they believe the complexity to be. When the majority of the team are estimating 2 or 3 story points and another member pops up with a 13 there is a disconnect. This is then the starting point for a discussion on the story. Does this person know of something that the others don’t, i.e. there is a hidden dependency? Is there a shortcut that this person does not know about?
In his book When will it be done?, Daniel Vacanti suggests that you don’t use story points for planning, but simply count stories. As we can see above, the estimate is a poor reflection of how long a story will take to complete, which confirms the Vacanti’s findings.
As part of the estimation the team may decide that the story is too large and should be broken up into more manageable chunks. In doing so we start to reach stories which are of similar sizes. Therefore, I believe that once the estimations have been made, and the team is in agreement about what needs to be done, the actual number can be thrown away.
When should the team estimate?
The original question in the post was asking when the team should estimate the size of the stories. Should this be as soon as the BA hands over the story, or should a dev put in some work designing before everyone starts estimating?
My feeling is that the story point value of the estimate is worthless, but the process of estimating and exposing unknown issues is high. Therefore, it makes sense to ask the dev team their opinions (with a round of estimation) as soon as possible, which means before doing any design.
There are two additional points to make.
- Feedback from an early estimate can be fed into any design tasks improving quality and efficiency. And,
- If there are any unknowns while creating the initial story the BA can setup a “three amigos” session pulling in dev and QA representatives to help flesh out details.
If anyone has any other opinions I’d be interested to hear from you.