If you’re putting together a new Agile team, you’re probably trying to document upcoming work in a backlog, establish team ceremonies, and clarify roles. These early steps are pretty clear-cut, but as the team gets ready to start work on this backlog you’ll need to know (1) how much work can my team handle per sprint, and (2) how much work is represented in this backlog? To answer both of these questions, you’ll need to begin pointing.
Pointing describes the practice of assigning points to each piece of work in the backlog to represent the amount of effort that work will require. Well, actually it represents the size of the effort, the amount of complexity it contains, and how much we don’t know about it. The more effort, the more complexity, and the more unknown, the larger the point value should be.
So why do we assign points? Because the team needs to know what it’s committing to. We want to complete the work we commit to each sprint, therefore we need to know how many backlog items we can realistically commit to. How else can you represent that feasibility?
Some people may argue that you should estimate how many hours of work each backlog item will require. That way you can fill up the Sprint backlog with the exact amount of hours each team member has to dedicate to the Sprint. If you have four people with 125 hours of capacity this sprint, just plug in 125 hours of work! Done!
Quick request: PLEASE DON’T DO THIS!!
Estimating with hours:
- Is too messy. There’s too much we don’t know! If your team has items in the backlog with any amount of complexity or unknown, their estimate will be wrong.
- Gives your team and your stakeholders a false sense of confidence. Once you assign an hour estimate, people believe that estimate. They will hold you accountable for that estimate. Which is especially frustrating since, as we pointed out, your estimate was almost definitely wrong.
- Creates a distraction. The success of your sprint is not defined by whether or not you met your time estimates. The success of your sprint is defined by the value you delivered to your customers. Hour estimates confuse the team members about where their focus should be and what success should be measured by. (Choose your actual success metrics in advance, e.g. throughput, team morale, customer satisfaction, etc.)
The Fibonacci numbers have increasingly large gaps between them, which helps to remind you that, the larger your work item seems, the less we know about it and the more likely something is to go wrong– so your estimates should go with larger estimates! It also keeps your team from getting “analysis paralysis”. Instead of splitting hairs about whether a backlog item is a 13 or a 14, you’re deciding whether it’s a 13 or a 21! Pointing should be quick and intuitive, not excruciating.
Take-Aways: Assign points to backlog items so your team knows how much work they’re committing to, use relative sizing and the Fibonacci sequence, and please please please don’t use hour estimates.
Questions: Agree? Disagree? What helped your team get the hang of pointing? Have you seen any success stories or cautionary tales with work estimates?
