So Agile is all about working software over comprehensive documentation right? But if I don’t know the detailed requirements up front, how can I estimate for a task? And if I can’t estimate for a task, how can we figure out how long the project will take and how much it will cost?
This post covers techniques for quickly and easily creating reasonably accurate, high-level estimates in the project kickoff meeting that are sufficient for resource planning and scheduling.
The Iron Triangle is a fundamental concept in software development that states that for a quality product, one of the 3 critical factors of scope (what must be built), cost (how much it must cost), and time (when it must be built by) must be negotiable.
In a Scrum project it is often the scope that is negotiable.
When it comes to producing high level estimates in the release planning meeting, the details of the stories available to the team will be fairly limited, so the estimates are based on certain assumptions on the scope.
For a happy client the amount of scope must be reasonable and acceptable, and the estimate made at the release planning meeting stage should be adhered to as closely as possible.
To realistically achieve this, the detailed scope of a story can be negotiated at the sprint planning meeting.
So, how do you quickly come up with accurate estimates for stories assuming reasonable scope in the release planning meeting?
Traditionally, estimates are absolute, i.e. the duration required to complete a task in hours or days, and are interpreted as a measure of elapsed time, i.e. assume in a 7.5 hour day a developer will complete 7.5 hours of stories for this product. However, things never go to plan.
The accuracy of estimates can be affected by things like:
- The developer’s inexperience with the problem domain
- Encountering unpredicted complexity during development
- The developer gets diverted onto other tasks
- Uncontrollable external factors prevent work on the task
- The person doing the work may not work at the same speed as the person who estimated for it
In fact, the only thing you can actually estimate is the perceived size and complexity of the story.
To eliminate some of this uncertainty and ultimately improve the accuracy of your estimates, some people recommend stating them in units of ideal time, i.e. ideal days or ideal hours.
Ideal time assumes no interruptions, the task was all you worked on and everything you needed was available.
But there are some problems with ideal time:
- Ideal time decays, i.e. over time on a project, developers’ skills increase, they become more knowledgeable in the problem domain and focused on a project, consequently the time it takes to achieve a task of similar size and complexity reduces. But the original estimates on which scheduling is based, can’t cope with this change very easily.
- It’s difficult to add it all up as one developer’s ideal hour may not achieve the same amount of work as another’s. Ideal time doesn’t factor in the variations in velocity of individual developers.
- Ideal time does not cater for instances where an initial estimate was wrong and how that should impact on the other similar stories in the backlog.
An alternative to ideal time is story points.
Story points are an abstract value expressing the size and complexity of a story.
They are unit-less, and tend to indicate the relative size of stories in the backlog rather than absolute timescales, which makes them quicker and easier to produce.
Story points do not decay. The amount of work stays the same but developers achieve more of it in a fixed time period therefore their velocity increases.
They are additive since they are developer agnostic – they imply complexity rather than time required to implement.
Even if a team is bad at estimating, as long as they’re consistently bad, the observed velocity makes a team’s commitments self-correcting.
So, if you’re using story points for specifying effort here are some techniques for coming up with them quickly and accurately:
- Triangulate – compare stories to other stories, e.g. story c will require more effort than story b but less than story a.
- Disaggregate – as effort increases, accuracy of the estimate decreases therefore break large stories (more than ~2 days) down into smaller ones.
- Collaborate – planning poker. For each item on the product backlog:
- Product Owner describes the story.
- The team discuss the story briefly.
- Pick a card from your set of cards consisting of 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 points.
- Everyone shows it at the same time.
- If estimates very wildly, discuss why until everyone’s estimate converges.
But how do you know how long a story will take if it’s measured in points, which are unit-less?
The real duration of a story is typically derived empirically from the number of story points you normally achieve in a sprint, i.e. your velocity. Using this you can work out which stories are achievable in a sprint and therefore which can be completed by the release date.
Following this approach the corresponding real time that 1 story point maps to, becomes less meaningful and less important.
The main thing is that the time or effort that corresponds to 1 story point will be constant across projects and teams to allow for consistent use of your velocity across projects, and so you don’t need to redefine the value of 1 story point for planning the release.
Over time as you deliver more projects you will develop a gut instinct of how many points to assign a story and be able to use historical data on previous similar stories from past projects.
However, if you are about to embark on your first scrum project you will not know how a story point corresponds to elapsed time, as you will not know your velocity yet.
You have to start somewhere. So why not start with 1 story point = 0.5 ideal days, and then migrate to thinking about estimates as unit-less over time.