How to get the end dates in a #Agile project – Practical approach to story point estimation!

Traditionally the estimates are given in days, months or person-hours with a probable end date to the project and these estimates do not include time in meetings, email, and other non-project related activities all of this considered to be as a “PROJECT BUFFER-TIME.”

Traditionally how it happens

Estimates for our project

• One month for design and architecture
• Four months for development
• One month for testing
• 15 days of buffer time

Scenario 1 – your estimation of design is off by two weeks, what do you do?

You have already given the date of the final deliverable. Usually, dates have an emotional attachment to them, and relative estimation removes the emotional attachment of the end date.

Scenario 2 – During the start of the project you do not know much of the requirements to start, would you have the higher possibility of wrong estimations?

The cone of uncertainty defines – during the commencement of the project the probability of estimates going wrong is very high, due to high degree of uncertainty.

“Story point represents the amount of effort required to implement a user story in a product backlog”

So while setting a story point of a particular user story in the product backlog, one would consider the following factors

1.   Risk

2.   Complexity ( which governs the effort)

3.   Uncertainty of the requirement ( which involves dependencies and doubts

The story points should estimates how long it will take to develop a user story all the factors such as the risk, uncertainty and complexity should be factored into effort involved in implementing it. Story points represent time; it is so because time is what our bosses, clients, and customers care. People only care about complexity to the extent it influences the amount of time something will take.

“Estimates may not be accurate, but they need to be consistent, the sprint velocity would correct the inaccuracy of the estimates.”   

The idea to compare your last given estimates with the following estimates time and again to reach consistency in your estimates.

Assumptions

• One of the most important considerations that need to be done while defining the story point is assuming the ideal day, where everything works as per the plan, no sick day; no one interrupts.
• No individual task should be more than 16 hours ( you can decide a number to define based on your project
• Assuming that your team size is constant and team understands their roles

Identification of the base/reference story

The breaking of the user stories until you reach to a small story which cannot be further broken. Making this is a base story or the reference story based on which you would relatively estimate the product backlog. It is important for creating the initial product backlog.

Tuning the base/reference story

After the team has formulated the initial product backlog, pick one of those stories that are a good representation of an “average” story from that list. Doing a relative mapping to the story against the average story and assigning a story point to this reference story. Moreover, realign the product backlog with the new number. The product backlog grooming is a continuous process which happens throughout the entire project.

Choosing the techniques for estimating

There are various techniques for assigning user story points to a user story. Common estimating methods include T-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8.)

Agile emphasizes that the story point estimation should happen at the story level, not at the task level

Some tasks might not be required as we come closer to the final delivery of the user story. One of the key things to remember during the estimation is working with the product owner and identifying the user story which is the most granular part of the product backlog which means it is naturally small or needs to be split. As a part of the sprint meeting the team needs to define two key points would the team able to take this user story in the current sprint or this need to be broken into smaller deliverable user stories.

Learn from past estimates

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools track story points, which makes reflecting on and re-calibrating estimates a lot easier. For example, pulling up the last five user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You will get better and better with time.