How to Estimate Project Features Better With Story Points

In this article, I will quickly explain why it's important in agile project management, To Estimate Project Features With Complexity-Points as opposed to estimating with duration/time.

Complexity measured by points

In Agile project management, there needs to be a distinction when estimating size and estimating duration of sprints. Whereas the traditional form of project management advocated estimating via time, more contemporary project management methodologies support the notion of estimating story complexities.

That is, you look at a particular story and based on various deductive tools, estimate the complexity and provide the story/feature with a story point, which then becomes the baseline for estimating other story points and whether they are larger or smaller than your initial one. The point is, you estimate relativity of complexity. For instance:- * I would estimate the story Develop UI widget at 2 points; * I then in the same sprint would say that developing the API call for the widget to be twice as complicated as the previous one, so I would put this at 4 points; * Unit testing the widget API I would put at 1.5 story points;

If the total sprint consisted of those stories, the estimated total points to be at 7.5. Now, the importance is not to get the raw values right, but to be consistent in how you judge and mark each story point. If you estimate Unit Testing at 1.5, and you have similar Unit Testing tasks in other sprints, give it the same 1.5. But how do you go about estimating story points?

Playing Poker

Estimating story points could be done by what is known as Planning Poker, whereby you can involve your entire agile team. You play planning poker by combining expert opinion, analogy and disagregation, dealing out each estimator (developer) an entire deck of cards, each containing an estimated complexity point.

Planning Poker

The cards would read out 0,1, 2, 3, 5, 8, 13, 20, 40, 100 (following the Fibonacci counting), and for each story, the moderator reads out the description and answer any questions in order to get a complete understanding. Don't spend too long trying to get an accurate estimate but rather be a bit conservative and quick. Each estimator then selects a card privately representing his or her estimate, and when everyone has finished selecting, the cards are flipped over to be revealed to the team.

If we do get different estimates across the table (which will most likely happen) people start to explain their train train of thought, then everyone gets to re-estimate again, until the entire table has the same estimate, or clear majority, in which case the moderator can negotiate and adjust with the odd estimators to conform.

Velocity is key

Velocity is the measure of a team's rate of progress, which is the sum of the number of story points assigned to each story that the team has completed during iteration.

Going back to our initial example when we estimated the three stories, if our team successfully completes those stories within the iteration, we can say our velocity is the sum of the 3 story points, which is 7.5. We would continue for one or two more iterations to observe what our velocity is by examining how we fare against the estimated total complexity points.

In Agile, We Estimate Size But Derive Duration

The estimated velocity would begin to stabilise and stay at a constant, which then means if we sum up the story-point estimates of all the features/stories of the project and we know our velocity, we can divide the size by velocity to estimate the number of iterations required to complete the project. This in fact affords the added benefit of self-correcting planning errors, as we can re-evaluate whether we require more or less iterations to complete our project.

But why pick Story-point estimation over ideal days?

In the book Agile Estimating and Planning by Mike Cohn, the author outlines several reasons why it's better to choose story points over ideal days.

  • Story points drive cross-functional behaviour by allowing teams to provide input across different functional areas of a team, allowing for earlier decision-making.
  • Story points estimates do not decay providing a longer half-life than ideal days, as it remains consistent throughout the project, regardless of whether the developer is able to complete something quicker after learning how to do something similar earlier on. Measuring velocity over time accounts for any complexity issues throughout the project, whereas ideal days would change based on experience.
  • Story points purely measure size pure and simple, whereas ideal days are not. The latter rather changes based on proficiency of the developer, which is hard to keep consistent, let alone account for early enough in the project.
  • Story point estimation is faster because its easier to work out compared to working out days. Story-estimation can be done at a higher-level discussion, without having to be bogged down in the technical detail.
  • Ideal days are not consistent because one developer's ideal day is different from another's, based on the skillset and experience of the developer, resulting in tight-coupling of the task to the resource by way of estimation.

So there you go, a simple explanation on how to estimate project stories with complexity-points.