Task estimation
Estimation is hard. For software developers, it’s among the most difficult if not the most difficult aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team and the business. With all that at stake, it’s no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that’s a mistake. Agile estimation is just that: an estimate. Not a blood-oath.
There’s no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let’s look at some ways to make agile estimates as accurate as possible.
Collaborating with the product owner
Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product owner new insight into the level of effort for each work item, which then feeds back into their assessment of each item’s relative priority.
When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that’s good: those questions help the entire team understand the work more fully. For product owners specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it’s not uncommon for a product owner to reorder items on the backlog.
Agile estimation is a team sport
Involving everyone (developers, tech leads, designers, deployers… everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.
Likewise, design changes require not only the design team’s input, but that of development and QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don’t feel included, and compromises the quality of the software.
Story points vs. hours
Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty. Values are assigned to more effectively break down work into smaller pieces, so they can address uncertainty. Over time, this helps teams understand how much they can achieve in a period of time and builds consensus and commitment to the solution. It may sound counter-intuitive, but this abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points:
-
Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.
-
Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.
-
Once you agree on the relative effort of each story point value, you can assign points quickly without much debate.
-
Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.
Unfortunately, story points are often misused. Story points go wrong when they’re used to judge people, assign detailed timelines and resources, and when they’re mistaken for a measure of productivity. Instead, teams should use story points to understand the size of the work and the prioritization of the work.
Estimate smarter, not harder: Try practical fibonacci
Because the Agile Fibonacci Scale is exponential rather than linear, it helps teams to be more realistic when looking at larger, more complex tasks. Also, we suggest to Split large stories: If you find that your story points are consistently hitting the highest numbers on the Fibonacci sequence, you could re-assess your user story and break it down into multiple stories. Re-estimate your story points and make your sprints more manageable. So, for everybody to have the same context, we will use these table estimating our tasks from 0 to 8.
For items deeper in the backlog, give a rough estimate. By the time the team actually begins to work on those items, the requirements may change, and your application certainly will have changed. So prior estimates won’t be as accurate. Don’t waste time estimating work that is likely to shift. Just give the product owner a ballpark figure she can use to prioritize the product roadmap appropriately.
| Value | Explanation |
|---|---|
| 0 | No effort (or minimal) is required. That means there is no business value delivered, so no points are accumulated for doing the work. This is also used if a task is added to sprints that a Scrum Master must complete. |
| 1 | Extra small. Developers understand the requirements and consider them easy to complete with a small amount of time invested. |
| 2 | Small. A little bit of thought, effort or problem-solving is required. It’s a repetitive and known task and the team can complete it with confidence. |
| 3 | Average. The team has done this a lot and they know what they are doing. It’s doubtful that they will need to research something associated with the task. |
| 5 | Large. This is complex work or the developers don’t do this very often. The team will need assistance from someone else or help with other tech areas. This is probably one of the largest items that can be completed within a sprint because it includes possible restrictions, dependencies or uncertainty. |
| 8 | Complex / Extra large. This is going to take time and research and probably the effort to complete it may involve several developers or teams. Additionally, we need to make several assumptions that could affect getting it Done. |
Learn from past estimates
Retrospectives are a time for the team to incorporate insights from past iterations including the accuracy of their estimates. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.
Like everything else in agile, estimation is a practice. You’ll get better and better with time.
Setting a time limit for sprint planning
Sprint planning should be constrained to no more than two hours for each week of the sprint. So, for example, the sprint planning meeting for a two-week sprint would be no longer than four hours. This is called “timeboxing”, or setting a maximum amount of time for the team to accomplish a task, in this case, planning the sprint. The scrum master is responsible for making sure the meeting happens and that the timebox is understood. If the team is happy before the timebox is finished, then the event is over. A timebox is a maximum time allowed; there is no minimum time allowed.
For more info about how me manage story points, please refer to our team confluence page