How does a backlog size estimate in Story Points translate to duration (time to complete the backlog)?



Here I discuss the curious case of mixing story points and person days and using them synonymously, not understanding what a monumental difference it is, in terms of arriving at a schedule using the two. While the team is using T-Shirt sizing (or planning poker) to come up with a backlog size in Story Points, they are using the words "Story Points" and "Person Days" interchangeably.

As a prologue to my previous post https://practicing-agile.blogspot.com/2019/08/when-you-equate-story-points-with-time.html - the objective in this one is to find the answer to the question - 
"How does a backlog estimate in terms of Story Points translate to how long will it take for the team to deliver the backlog, given that requirements, technology and a lot of various other factors influencing estimates are bound to change?"

In other words, if the backlog size is 120 Story Points, its equivalent to saying that the backlog is worth 120 PDs of work! A derivation from the latter for a cross-functional team of 4 and a backlog of size 120 PDs will be: 120/4 = 30, which means it'll take 30 days to complete the backlog by the team.

 Increase the team members and voila! You finish sooner. Aint it? Add 2 members more to the team of 4 and the math becomes - 120/6 = 20. That is, with two more members in the team, you finish a backlog worth 120 PDs, 10 days sooner!

Being pragmatic, are all team members the same? Do they all have the same skillsets, expertise, experience...? Hell no! Are all of them going to be coming to work every day? Will there be no absence due to sickness or personal reasons or holidays? No right?

 Then how can we use person days/man hours to derive the schedule given that there are a lot variable factors (human, environmental, political etc.) that contribute to team's productivity? This is where estimation using Story Points comes to rescue in Agile.

I've already discussed the benefits of using Story Points to estimate size and complexity of a user story/product backlog in my blog https://practicing-agile.blogspot.com/2017/03/. The sum of story points of all the user stories accepted by the Product Owner equates to the velocity of the team. A few key things about velocity -
  • Its the rate at which a team can produce working software
  • Used for estimation and planning
  • Measured in non-time-referent terms (Story Points)
  • Should not be used as a measure of comparison across teams
  • Last and the most important of all: Velocity = f(# of team members, skills, learning, distractions, sickness, absence, changes, Murphy, ?)
That said, and sticking to using Story Points, it's easy to derive the duration knowing the size of the backlog (in Story Points) and Velocity of the team (in story points again). 

 Let's go back to assuming that the backlog size is 120 SP and the team's velocity is 20 SP. The derivation that one can make using this is that it'll take 120/20 = 6 sprints to complete the backlog. That gives us the time it'll take to finish the backlog! How? Assuming that the team is using a sprint worth 2 weeks (or 10 working days), it will take 6 x 10 = 60 days for the team to finish the backlog.

 Wasn't that straightforward?

Best,
Jasdev Singh (PMI-ACP®, CSM®, CSP-SM™, ICP-ACC)

Comments

Post a Comment

Popular posts from this blog

Increasing your Agile Team's Outcome Predictability

Image
Understanding Predictability in Agile Team Outcomes   "Understanding Predictability in Agile Team Outcomes" refers to the study or analysis of how consistent and reliable the results or achievements of a team practicing agile methodologies can be. This involves examining the factors that contribute to the team's ability to deliver on time and within scope, as well as identifying potential challenges or obstacles that may impact their predictability. By understanding these dynamics, organizations can better manage and optimize their agile teams for more consistent and successful outcomes. In today's rapidly changing world, the significance of accurate weather forecasts cannot be overstated. Similarly, in the world of software development, predictability is crucial for Agile teams. The ability to deliver outcomes predictably is a key factor in Agile team success. Achieving predictability can be challenging for Agile teams due to various factors such as capacity planning
Read more

Stop starting, start finishing.

Image
Limiting WIP & reasons for high WIP My first post on Kanban  deserved a sequel for sure! While it isn’t possible to have literally no work in progress, the overall goal of a project team is to finish as many things as they can, and not be in a state of continually starting. Having too much #WIP makes this goal even more difficult.  The impact of too much WIP on efficiency and throughput is one of the reasons it is often regarded as a concern. According to studies, the cost of context change is frequently far more than people anticipate. It is evident that dropping one object and taking up another cannot be done in such a way that no time or energy is spent between the two. However, there is sufficient evidence to suggest that the loss is rarely worth the gain. These apparent consequences of having too much going on are easy to identify once you know what you're looking at. Looking around the team, you'll notice that there are many tasks open, few of which are done, and many
Read more

Mastering the Daily Scrum

Image
- A Key Ingredient for Agile Success Introduction: In the fast-paced world of software development and project management, staying on top of tasks, priorities, and progress is essential. The Daily Scrum, often referred to as the Daily Standup, is a cornerstone of the Agile methodology. It's a brief, focused meeting that empowers teams to synchronize, collaborate, and make data-driven decisions. In this blog post, we'll dive into the what, why, and how of the Daily Scrum to help you harness its potential for your agile projects. What is the Daily Scrum/Daily Stand-up? The Daily Scrum is a daily ritual (a scrum event) that brings the entire team together for a brief, time-boxed catch up. Its primary objectives are: Synchronization: Ensure that everyone is on the same page regarding the sprint goal and knows what to work upon given the priority. Collaboration: Encourage open communication among team members. Identify and Remove Obstacles: Highlight any impediments that need res
Read more