User Story Estimation – Affinity Table

How to Estimate User Stories For Agile Development

Estimating a user story is hard! How can we get the best estimation of a story size? Some people said the best size should be estimated in terms of story point, and the other prefer they are estimated in terms of hours or days.

Well estimating is definitely hard, but there are a few concepts that can help us in the user story estimating process:

1. Estimate user stories in relative terms from two aspects
   • Work effort
   • Risk (such as, Complexity and uncertainty)
2. Estimate user stories using story points
3. Place those user stories in the affinity table that you have higher confident of estimation in terms of work effort and complexity (risk)
4. Gradual estimate the other lesser familiar kind user stories to in terms of work effort and complexity by comparing them with those stories that had already been estimated in the affinity table.

Affinity of User Stories for Estimation

Estimation of a user story can never be 100 percent accurate and in fact no method can achieve this. To improve the accuracy of estimation, we start off by deciding the sprint length (say, two weeks, or 10 working days) and perform estimation on a few user stories that we feel most comfortable with in terms of estimation (say, 5 days and the certainty is medium). In this case, you will put the story in the middle vertically (certainty or risk level) and horizontally (work effort is equal to 5 day, or half of the sprint length, which is 10 days). You can then use it as a reference point in estimating the other user stories. Ask yourself whether this user story requires more effort than the referenced one, or less, and has more uncertainty or less). As you place some more user stories onto the Affinity Table you can compare among several user stories to determine whether the offsetting is logical or not, and then juggle them around to make them fair and that’s it. The process is a little bit more an art than engineering. Do it and discuss in the team meeting rather than any confrontation. The accuracy will usually be improved as the team get more mature.

How Affinity Table Calculate? (Watch A Video) 

To understand how the story point and days are estimated automatically in the Affinity Table, we need to understand that the horizontal grids represent the work efforts, increases from the left to the right, and the complexity of the story development (such as new technology, new domain and etc.) increases from the top to the bottom.

As the maximum number of days for a user story to be developed should be no more than the length of the sprint (if not either the user story is to big that needed to be broken down, or the sprint is set too short which requires an extension), so the number of days of the bottom right grid should be also be equal to the length of the sprint. Based on this assumption, the story estimation can be calculated automatically.

Note that: In the first example above

Story Point = Effort x Risk (e.g. 3 x 4 = 12)

Story Point Unit = Total Number of Point / Sprint Length (e.g. 100 / 20) = 0.2

Story Days (hours) = Story Point / Story Point Unit (e.g. 12 x 0.2) = 2.4

Eliminate Risks with Project Spike

According to Agile Dictionary the definition of Spike is:

“A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike”, which is some work whose purpose is to provide the answer or solution.”

When estimating a user story we not only consider the development effort, but also take into considerations the risks and uncertainties involved. Quite often, a spike is created before the formal commencement of a sprint in managing the work required to be performed in order for some other user stories to be estimated fairly.

Download and Try Now!