How to calculate Sprint user story capacity for first newly started scrum based on the known team capacity in hours?

Last post 11:00 pm February 25, 2019
by Ian Mitchell
12 replies
Author
Messages
03:24 pm June 16, 2018

Hi,

Can anybody help me to know the answer for below question?

Suppose I am starting scrum for the project who is really not much aware about Agile methodology at all. I have scrum team size of 7 team members with weekly capacity 7 (Team count) x 6 (Potential hrs) * 5 (No of days in week) = 210 hrs.

Consider that below is the priority and estimate of the 10 user stories.

User story 1 = 1 Story Point

User Story 2 = 2 Story Points

User Story 3 = 3 Story Points

User Story 4 = 5 Story Points

User Story 5 = 13 Story Points

User story 6 = 1 Story Point

User Story 7 = 2 Story Points

User Story 8 = 3 Story Points

User Story 9 = 5 Story Points

User Story 10 = 13 Story Points

 

So total story points are 48.

Now I have two questions how to decide that how many user story points of work we can consider in first sprint? Though I know the weekly capacity is 210 hrs, this information won't help me to decide user story capacity in first sprint since I am just aware about 48 story points of work which I can't convert into hours as agile says not to do this.

In nutshell, how can scrum master and team decide how much user story points of work can be considered out of 48 user story points of work with the known information of 210 hrs weekly capacity of the team? Also how can decide scrum length based on the above information?

Weekly team capacity = 210 hrs

Calculated User story points in meeting  = 48 Points

User story points consideration for first sprint = ?

Sprint Length = ?

Team is new to Agile and it's a first scrum in project

Kindly help.

 

 

 

04:09 pm June 17, 2018

Correcting the above question

How to calculate Sprint user story capacity in unit of user story points for first sprint based on the known team capacity in hours for the scrum team which is completely new to agile scrum process?

02:49 pm June 18, 2018

User story 1 = 1 Story Point

The development team may estimate the hours need to implement the user story 1.

The value is the hours per story point.

 

03:01 pm June 18, 2018

Though I know the weekly capacity is 210 hrs, this information won't help me to decide user story capacity in first sprint since I am just aware about 48 story points of work which I can't convert into hours as agile says not to do this

Bina,

Why do you need to play any role in what the Development Team decides they can forecast in their first sprint?   As a Scrum Master, you should help the team as much as possible (i.e. - capacity and velocity metrics), but ultimately it is the Development Team's decision on what they feel they can complete.

Keep in mind, we're talking about estimates.   Agile is not about perfection, but improvement.   Start out with your best guess, and go from there, trying to get better in your estimates and forecasting each sprint.

Sprint Length = ?

Just curious, how can your team make a forecast when the time box has not been decided yet?

04:03 pm June 18, 2018

So if they are new to scrum I'd stay away from story points all together for a few sprints. 

My hunch is neither you or the team understand story points and you are creating your own problem. 

I personally detest story points. I build up to story points over time I don't use story points at all until I can asses a team gets the basics of what sprints , time boxes etc are. 

That capacity you have calculated does not equate to the number of points your team can complete. People get that confused early on  capacity does not = velocity. 

04:09 pm June 18, 2018

Bina, I would suggest reading through the scrum guide again. You're asking how the Scrum Master can decide the amount of stories that will be worked on and how the SM can decide the length of the Sprints. The SM has absolutely no right to make that determination. Sprint length is determined by the Scrum Team (Product Owner + Scrum Master + Development Team), it is a mutually agreed upon length. The accepted norm is 2 weeks, so discuss with your team and throw that out as an option. For a newly formed team, I would say 1 week is a bit too short, 4 weeks is a bit too long, so either 2 or 3 weeks will likely be a happy medium. After a few sprints, talk as a team to determine whether the decided length is working or if it should be adjusted. Worst case scenario, you change it to a different length and it doesn't work; go back to what you know has worked.

As far as the amount of work the Development team will do, the SM or PO have no say in that. The Dev Team decides what they will work on, the PO can provide insight of priority levels for the backlog items but if the dev team decides to choose 30 points or 10 points, it is their right within Scrum to do so and no one can block that. The SM's role is simply to encourage the team to consider previous sprints and consider the potential risks when planning what work they will do. I also think you're focusing far too heavily on the numbers of capacity and velocity and expecting there to be a mathematical formula that you can apply to find the best amount of story points to be used for each sprint. Scrum is founded on empiricism, that is making decisions based on what is known. The calculation it seems you're looking for doesn't take into consideration the experience level of the dev team members or the tools that are available to them or the roadblocks that they encounter. The best thing you can do is support your team, let them make the decision and you help by keeping track of the data so it can be used later to inspect and adapt. Even if you disagree with what the team chooses, support them. Let it be a learning time for you and the team.

Say your team decides to have 3 week sprints and they choose 45 story points. At the end of the sprint, they have completed 25 points; AWESOME! The items that were not completed goes back to the backlog and the team can select them for the next sprint. They learned that 45 was just too much to accomplish at that time. Next sprint they choose 25 points because that's the amount they completed in the prior sprint. Halfway through the sprint, they complete all 25 points; GREAT! Go back to the backlog and select a few more items to work on for the remainder of the sprint. The team now has 2 sprints worth of information they can further inspect and adapt. The team can work and discuss together to determine what the variance was as to why they completed such different amount of story points within each sprint; was it an issue with capacity or competency or maybe an issue with story estimation? They continue on this cycle until they get a better understanding (through empiricism) proper story estimation, sprint planning, and based on the past they can make better decisions as a team.

The great thing about Scrum is the ability to constantly inspect and adapt. Try something out for a sprint then talk as a team and decide if it helped the team. Did the team love it? Great, keep using it. Did the team hate it? Great, stop using it and find something else. This is a new team, as you mentioned, any expectation to not "fail" is wrong. The team will fail, and that's a great thing because they just learned how NOT to do something and it will prevent or at least deter similar failure in the future.

Lastly, get rid of everything you and the team think about typical project management. Adopt an open mind and mentality that has no problem with trying new things and no problem with trying something and failing. I recently learned a bit more about the Spotify method of Agile and one thing that stood out to me was their feelings about failure; they love it! Why though? Because they just found stuff that doesn't work, it provided great information to use for the future, they can improve from failure very easily; much more easily than success.

05:06 pm June 18, 2018

How to calculate Sprint user story capacity in unit of user story points for first sprint based on the known team capacity in hours for the scrum team which is completely new to agile scrum process?

Before considering capacity and potential Sprint length, do the Development Team have:

- a Definition of Done which is of release quality?

- all of the skills and resources needed to meet that Definition of Done?

In other words, are there any stories in the Product Backlog which the team would be unable to fully develop, integrate, test, and release immediately into production by the end of the Sprint? Is there any work they couldn't complete entirely under their own steam...even if it that story was the only one being worked on, and the Sprint was time-boxed to the maximum of one month?

06:49 pm June 18, 2018

+1 Curtis.

 

@Ching-Pei Li, that is an incorrect application of relative estimating.   You should never equate a # of hours to a story point.   If you prefer to do so, why not simply cut out the waste and use hours instead?

Story points are relative estimates.   Think in terms of t-shirt sizes (XL, L, M, S, XS).   Just place the item in its properly-sized bucket.

03:23 pm February 24, 2019

Hi all,

If we use only story points and never map story points to hours, how can we arrive at the initial estimate for a  scrum project (release) for a fixed price project and convince the customer about this price?

Narayana murty

 

 

 

 

 

 

06:19 pm February 24, 2019

Hi all,

If we use only story points and never map story points to hours, how can we arrive at the initial estimate for a  scrum project (release) for a fixed price project and convince the customer about this price?

Narayana murty

 

 

 

 

 

 

10:21 pm February 25, 2019

Does the team(s) have a history of performance (i.e. - velocity) upon which projections can be made regarding dates of delivery?

Keep in mind that Agile/Scrum is designed primarily to incorporate empiricism in response to change.   Therefore, the scope in an Agile project is not truly "fixed", even though the target delivery date may be.

The only questions then are:

  • How much of the original scope will be delivered by the due date?
  • How much "new" scope will be delivered by the due date?
  • How much of the original scope will either be shelved or not delivered?   

Keep in mind that, if team(s) are working from the most critical business value items to the least valuable, then any items not delivered or shelved should have little business value

10:37 pm February 25, 2019

Sounds like you want to determine two things:

  1. How much work the team can estimate they will complete in the sprint
  2. How long will it take to delivery a set of user stories.

Here's what has worked for teams I have worked on.

To determine how much work the team can bring in to a sprint:

  1. Select a user story to bring into the sprint
  2. Break the work that the team needs to do down into tasks
  3. Estimate those tasks with hour values (even a rough estimate is OK)
  4. Ask the team if they think they have enough for the sprint. If not, repeat from step 1. Validate the estimated hours against the capacity as a sense-check

Notice that there is no mention of story points or velocity here. As Mike Cohn (and others) have said, velocity is a poor measure of short-term planning. It's useful for long-term planning.

To determine how long it will take to deliver a set of user stories:

  1. Determine a velocity for the team
  2. Determine the total story points for the user stories for the release
  3. Divide the total by the velocity to get the number of sprints.

If you don't have a velocity (e.g. at the start of Sprint 1), you could try a few approaches:

  • Use the total story points that the team has brought into Sprint 1, with the caveat that it may be wildly innacurate
  • Guess based on what the team has brought into the sprint
  • Don't provide a velocity at all until Sprint 1 has completed

This is not a set rule and others may disagree, but this is what has worked for me and what I've read in other places.

11:00 pm February 25, 2019

If we use only story points and never map story points to hours, how can we arrive at the initial estimate for a  scrum project (release) for a fixed price project and convince the customer about this price?

If it’s price that’s fixed, rather than scope or time, what is there to calculate apart from the number of Sprints the customer can buy?