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

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?

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.

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?

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. 

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.

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?

+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.

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

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

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

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.

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?

What is the purpose of capacity planning and how can we calculate for a team and how we can convert to hours or story points

Difference between capacity planning and velocity

@Vijay Sprint Velocity is the average completed (estimated) story points over the past three to five iterations. Team Capacity is a product of the total number of Scrum team members multiplied by the number of team productive days, this also takes into account, planned annual leave, contingency for unplanned, bug fixing work etc. I hope this helps. 

I am going to counter @Joseph a bit.  I'm not saying his answer is wrong. I'm saying that there are multiple ways to answer the question. This is mine.

Velocity is the rate at which work is done.  Story points are estimates (i.e. guesses) made at a point in time based on the information known at the time. As soon as you start to work on the issue, new information is gained and the original estimate is no longer viable. They in no way represent the amount of work that is being done. 

Using flow metrics like throughput or cycle time will help you to better determine the amount of work that can be completed in a specific duration.  In my opinion, those are better indicators of velocity. 

Capacity Planning is the activity of trying to determine how much time is available from the people doing work and attempting to match the most valuable work with that value.  Here, @Joseph's answer is closer. However, he leaves out the variable of number of hours worked each day and how much of that time is available to focus on the work being considered.  This is important because is it extremely unusual that the entire time they are being paid to work will be available.  There will always be some time spent on "other duties as assigned". 

Having said all of that, the idea of capacity planning is not something that is used much in an agile organization.  The focus is on the team delivering value and not on how many hours an individual works. The team will commit to a body of work (Sprint Backlog) in a specific time frame (Sprint timebox) and do the necessary work to deliver on that. 

how can we calculate for a team and how we can convert to hours or story points

You can not and should not even attempt this.