Scrum - How to decide the capacity of user story points in first sprint with known team capacity of the team in hours?

Bina, I replied to your other post that is similar to this. There is no Capacity of User Story Points, you're referring to the Velocity. There is no velocity in the first sprint; it's all guess work. Once your team has decided upon your sprint length, your developers should be able to look at each point and have a ballpark estimate of the time it will take to work on something. They can decide how much to choose for the sprint.

No data -> make an informed guess -> execute -> inspect & adapt.

Focus on GATHERING empirical data before using it. First few Sprints will be used to gather this information. At the end of the Sprint you will know how many story points the current team with their current level of understanding of the process and functionality can achieve which is let us say 30 points. So now you have some data from your first Sprint ! Your team can do 30 points / 210 hours = 1/7 points per hour or 1 point for every 7 hours.

Now for the next sprint the SAME team estimating the SAME backlog (means same business domain and technical aspects needed) working the SAME hours (without holidays and sick leaves) will probably achieve the SAME velocity right?

That means if the new available hours (after accounting for holidays and planned off time from team members) is lets say only 175 hours, how many points would you comfortably be able to finish? 1/7 X175 = 25 points. So select 25 points for the next Sprint in the planning session with the limited information you have keeping in mind to be ready to take more as the team efficiency and understanding of the product and tool use increases. And let us say you were actually able to achieve 28 points (more than the forecasted 25 points) 

Now , based on the latest empirical data your UPDATED velocity which is more accurate and current is (30+28)/(210+175) = 1/6.6 points per hour or 1 point for every 6.6 hours

So for the next Sprint if you know you have 210 hours you know you can comfortably pick 210(1/6.6) = 31 story points

This is how you give more importance to observing and inspecting what is happening to predict what is going to happen. The true value of the velocity is in it's ability to help you plan better for each Sprint. With each sprint the new data gives more accuracy to your forecasts.

@ Uma-Venkata. My only issue is you're calculating a constant/fixed value (hours) against an arbitrary/fluctuating value (story points).

That would like trying to determine how long it would take a vehicle driving 70 mph to drive a few hundred miles. "Few hundred" could be 200, 350, 625, or other because it's an arbitrary value.

If you want to be able to use a simple calculation like this for your planning; why even use story points? Why not just use hours instead?

Can somebody help me to know how to decide capacity of user story points

The purpose of estimation is to help a Development Team to figure out how much work it can take on. Story pointing is just a means to that end.

If a Development Team has estimated conscientiously, then team members will have obtained an understanding of how much work each Product Backlog item is likely to involve. That shared understanding is a more critical output of refinement than any numbers.

A team could estimate using t-shirt sizing for example. They might have no notion of story point capacity at all, but they would nevertheless appreciate the scope of the work they have discussed, and whether the forecast to meet the Sprint Goal would likely be achievable in the time-box. That appreciation should improve over subsequent Sprints.

Thank you Curtis, Filip, Uma and Ian for your valuable response. It will help me a lot!!

One more question related to reflection of estimation in JIRA. Suppose I have User Stories as below:

Epic1 - 8 User Stories (Addition of userstory1 and userstory2 estimate))

 UserStory1 Under Epic1- 3 User Stories (Addition of Task1 and Task2 Estimate)

  Task1 under User Story1 - 1 User Story Points

  Task2 under User Story1 - 2 User Story Points

 UserStory2 Under Epic1- 5 User Stories (Addition of Task1 and Task2 Estimate)

  Task1 under User Story2 - 2 User Story Points

  Task2 under User Story2 - 3 User Story Points

 

JIRA board shows total estimate as 24 (8+3+1+2+5+2+3) Story Points?

However It should show only 8 user story points since rest of the estimates break-up of the estimate for EPic1 and it should not add.

What can we do so that JIRA can show Total sprint estimate as 8 user story points and not 24 story points.

Also can we have both units available (Story points as well as hours) for tasks level estimate?

I believe tasks should be estimated in terms of hours only. Or everything should be in terms of story points or we can have estimation of user stories in story points and subtasks in hours?

Please let me know what should be the exact approach.

Many thanks

What can we do so that JIRA can show Total sprint estimate as 8 user story points and not 24 story points.

I think there is something off with your configuration in JIRA or how you setup the stories. Honestly, I'd have to look at it in order to help further.

I believe tasks should be estimated in terms of hours only.

Why? If it is strongly discouraged to estimate stories as a whole in terms of hours, wouldn't that same thought process apply to the tasks as well? What benefit would you get from estimating the tasks in hours but the stories in story points? I would go one way or the other for everything. I don't like estimating with hours because there are always interruptions that take away from that time based estimate. The other benefit of using story points is the team can tweak and fine tune their estimations with more flexibility to better fit the team. Using hours, you have a single variable that is fixed. 1 hour will always be 1 hour but 3 story points can change drastically throughout the course of a team using agile thanks to the process of empiricism.

I've heard it said that it can be helpful for a Development Team to use hours, once they get to Sprint Planning, and are producing their Sprint Backlog.

I think it's important to draw a distinction between making relative estimates for the purpose of refinement, prioritization and longer term forecasting – and developers setting out how they will plan their work towards a Sprint Goal.

It's not a practice I've tried, but I see nothing wrong with a development team choosing to do this. However, it really must be the choice of the team.

To me, one thing that seems to be overlooked in this discussion is that we're talking about estimates, which are best-guesses based on the information at hand.

What information/tools do we have?   

• Projected available team capacity in hours (an educated guess)
• Product Backlog Items relatively sized in story points by the team doing the work (an estimate)
• Calculated team-velocity, if the team has completed several sprints (a calculation based on empirical evidence, which were derived from estimates)
• Team member expertise

With this information, just present the "offer" to the team according to the decided Sprint Goal, and ask the team how much they feel they can accomplish according to the DoD within the given sprint time box, using the available information.

One thing that traditional project management gets wrong (one of many, in my opinion) is that it tries to treat estimation as an exact science.   Estimation is, by definition, non-exact.   They are nothing more than guesses.

So, ask your team to make a guess, and work with your team to try and make better "guesses" in the future (if needed).   Don't over-complicate this.

+1 Tim! 

My only issue is you're calculating a constant/fixed value (hours) against an arbitrary/fluctuating value

Curtis, Not true. Nothing is fixed except for the UNITS! Both the story points and total number of hours are expected to change ! The only thing that is constant is the ration (Story points/Hours). Each Sprint you simply calculate the total number of story points and the total number of hours (by entire team actually billed after leaves and all).

We of course measure the total time spend per story to get an idea of what our story points ended up as. For example we realize that what we thought 1 story point actually took on an average 20 hrs and what we though 3 story points actually took 28 hrs (not necessarily 60). Each sprint we measured this and currently our values are as follows.

1 Story point means 16 hrs based on our teams historical data (this will be different for each team)

2 story points means 22 (not 32 !) based on our teams data

3 ended up being 35 at this time.

Again for next sprint we will use hrs only when needed because we still use story points covered on an average per unit of hour to calculate our velocity. We understand that our understanding of the story point improves each sprint and our estimates get even better. Story point to measure compared to SAME team estimating the SAME backlog so usually they end up allocating similar UNITS for SIMILAR Stories anyways. All you need to do is compare these (assuming their reasoning and therefore their story point estimation is usually going to be the same) points delivered per hr for each sprint and extrapolate for future sprints.

My only issue is you're calculating a constant/fixed value (hours) against an arbitrary/fluctuating value

My last response seems to be too lengthy without directly addressing your above assumption. Let me address that here.

You are right that the story point is an arbitrary value, but it is not fluctuating within the SAME team and SAME backlog. It of course can fluctuate and will be different between two different teams.

That is why velocity is used to calculate within the team to predict its future performance compared to its histrocial performance.

I do not agree that the story point value fluctuates much within the SAME team working on the SAME backlog over time especially once the team has matured and estimating its backlog, and this is my basic assumption in relying on this method.

JIRA board shows total estimate as 24 (8+3+1+2+5+2+3) Story Points?

Bina, JIRA sums the total points. This is what we did

• We used story points only for Stories
• Epics do not have any measurement (We did not find the need)
• Tasks are estimated and measured in hours, not points. Team puts remaining hours and keep updating the actuals daily.
• Simply show (add it to the presentation , JIRA admin work) the same time field on Story . It will show the actuals summed for all tasks under it.
• The same time field ( forgot what it is, but you can inspect what you have on story and reuse it in the presentation for Epic on JIRA ) will show the total time across all the tasks under all user stories on that epic (though we never felt the need to get actuals at epic level)
• At the end of the Sprint we created an excel sheet to depict in each row (we reviewed it in retrospective), each story (ID and may be title)- originally estimated story points - actual hours spent , to get the value of what each story point ended up. These values started getting consistent with each sprint we progressed!

Many thanks Uma, Curty, Timeothy and Simon for your response.

@Uma, can you please let me know the exact field in JIRA which automatically calculates the total estimates of user story by adding the estimation of tasks under it?

I have further query regarding your below comment

• We used story points only for Stories
• Epics do not have any measurement (We did not find the need)
• Tasks are estimated and measured in hours, not points. Team puts remaining hours and keep updating the actuals daily.

As per your above comment

Suppose I have one user story for which estimate in user stories is 2 which was decided by scrum team in sprint planning meeting.

However, suppose there are two tasks under this user story. Estimate of one task has been provided as 3 hrs and estimate of other task has been provided as 5 hrs.

So do you mean we need to add some time field in user story screen where it will automatically reflect the total time of user story as (3 hrs + 5 hrs =  8 hrs)?

What about the estimate which has also updated for the same user story as 2 user story points?

Also how can we plot the burn down chart when team can't be able to provide how much user story points of work is remained? They can just update the total number of hrs work they have done so far for particular date.

e.g. Team member  who working on above issue was just able to work for 2 hrs on first day and was not able to work for the complete day. He or she can't guess and will be in position to tell how many user story points of work he or she has completed. He can just update total remaining hrs of work as 6 hrs and not in terms of story points.

In such case which option should we consider in burndown chart's Y axis. Is it user userstoriepoints ? But team member has just updated the time worked and remaining in hrs under each tasks. Then JIRA's burn down chart will reflect what? X- Estimation in Hrs and Y axis dates.

Suppose my target was 8 user story points of work and team has finished only 2 hrs of work on first day. Tell me can we plot a burndown chart  on JIRA since we don't know how much story point of work is remaining but we know 6 hrs of work is remaining. The same can be plotted if estimation of user story in hrs. e.g. from 8 hrs of work now 6 hrs of work is remained. But having use story estimate in user story points and subtask estimate in hours will not help to prepared a burndown chart since team members will just update the reamaining work in JIRA in hrs only and not in user story points.

Many thanks.

Please confirm.

Thanks once again for your time.

Continuation of above question..

Is there any site or video which can show a complete scrum process including estimates and different Metrics in JIRA which we can implement for our project? Sometimes I feel that Agile scrum's theory knowledge is actually not helping 100% while implementing it in live.

e.g. Different opinions about user story level and task level estimate process and then confusion of preparing of burndown chart based on the different estimate units for user stories (e.g. in Use story points) vs estimate units for associated subtasks (e.g. in hrs) assuming team member will just update the work completed everyday in hrs at JIRA.

If there is any good video around actual practical implementation of scrum using JIRA then please share the link.

Thanks Uma, Curty, Timeothy, Simon, Ian and Filip for your valuable time.

Bina, 

Please refer here. There is a lot of documentation out there and the backend field names slightly vary based on the version of JIRA you are using, 

https://confluence.atlassian.com/jirasoftwarecloud/advanced-searching-f…

Look for the field called "Time Spent" on this (above link is already tabbed to that field). 

you guys may also think about using work ratio field. the above guide clearly explains how each field works.

please refer to this youtube video: https://www.youtube.com/watch?v=iwfrkiiuknI&list=PLjYflIjksc6iR1eLJ-d7b2yP_UUgalckL 

I strongly urge you and your team to read this article explaining SEVERAL best practices for estimating and tracking using JIRA fields (story points, estimate, time spent (time log)) etc. 

https://confluence.atlassian.com/jirasoftwarecloud/estimating-an-issue-…

Again Estimate is "ESTIMATE" NOT supposed to be ACCURATE. My focus is always on trying to figure out what our estimates ended up using real data once the time logs the time against each activity or even better the total time spent by the team and total points the team completed as estimated by them each sprint. 

I avoid individual task time logging until the team feels comfortable and understands the purpose of measuring is to measure the TEAM's efficiency and not an individuals !

Bina, use the Time tracking field! , that will show the total time estimated for all tasks summed under the story and the toal time reported against all tasks under the Story. Sorry, I moved to a different client and working with VSTS now , but did a lot of administration on JIRA until 8 months ago :) 

https://confluence.atlassian.com/adminjiraserver072/configuring-time-tr…

https://confluence.atlassian.com/adminjiracloud/configuring-time-tracki…

So do you mean we need to add some time field in user story screen where it will automatically reflect the total time of user story as (3 hrs + 5 hrs =  8 hrs)?

Yes, there is a field that will show the estimated time in hours (based on task estimates) and the time spent (based on the task time spent total). 

You are complicating this too much. For example, your estimate of 8 hrs WILL most probably end up as 14 -16 or more hours when you are actually done after identifying all tasks and work (that you initially may have missed) during your sprint work. In the end al matters is that what you said as 2 points ACTUALLY took 15 hrs !

Like I said the focus should be on LEARNING what your team's sizing ended up as so the team will get a feel of what their relative estimations mean and can estimate better in future. 

During refinement estimate as many backlog items as possible in story points. Measure how many story points you were able to complete this sprint extrapolate the graph ! Keep adjusting with new velocity data from each sprint. Simple!

e.g. Team member  who working on above issue was just able to work for 2 hrs on first day and was not able to work for the complete day. He or she can't guess and will be in position to tell how many user story points of work he or she has completed. He can just update total remaining hrs of work as 6 hrs and not in terms of story points.

Micromanagement !

But having use story estimate in user story points and subtask estimate in hours will not help to prepared a burndown chart since team members will just update the reamaining work in JIRA in hrs only and not in user story points.

Why are you concerned about how the team estimates their work in sprint? Just measure the whole item once its actually done. FORGET about the actual time it ended up. Keep this information for retrospective so the tam will use it for better story point estimation of future backlog items. This is how JIRA uses burn down charts.

https://www.atlassian.com/agile/tutorials/burndown-charts

If you want to calculate at task level feel free to export the Totals in hours and totals spent in hours and generate a graph using time instead of story points = micromanagement according to me.

Thank you so much Uma for taking care of my each and every query. Very much appreciated!

Let me go through all links as well provided by you. Hopefully these will help me a lot!

I would like to again say thanks to you, Timothy, Curtis, Simon, Ian, Filip and all who helped me to provide their inputs for my all queries.

Curtis, Not true. Nothing is fixed except for the UNITS

Uma, an hour is an hour, it doesn’t fluctuate, only the number of hours fluctuate. The same is not true of story points. 2 story points does not have a fixed value. It could mean x amount of work at a given time and later it could mean a completely different amount of work; even for the same team and same product. That was my point. In a mature team, fluctuating is less likely but it takes many teams several months to even several years before they truly get a strong hold on estimation so that the story points do not fluctuate. 

I agree with Tim in that doing all of these calculations against an estimate is just a bit too much. It’s a best guess, no matter how mature or educated a team is; it’s still an estimation and not a fixed value. Therefore trying to calculate it out just seems like a waste of time.

@Uma

What is the point of relating Story Points to hours at all?  Why not just use hours?

What is the point of relating Story Points to hours at all?  Why not just use hours?

Alex, I think I sent out wrong understanding. Our effort is not to anticipate or estimate anything in hours. We are just realizing (discovering and learning) what our story points ended up as, after each sprint.  The expectation is that our understanding of what each story point number (1,2,3,5,.) means will gradually improve and normalize within the team though it can be completely different from a different team (even working on the same product backlog) as each team will has their own understanding of these numbers and the velocities are not same for the same team size working on same backlog. 

The assumption for us to use this method however is that this collective understanding will remain CONSTANT within the team working on the same backlog and therefore we can PREDICT how much each team can accomplish in future sprint compared to that team's historical velocity data.

How and when we use the collected information: When we are nearing the end of Sprint we use the collected averages (observed hours it took for each story point) from the most recent sprints (2-3 , but not from the beginning where our team is still normalizing its understanding  of the product, tools and skills) so the type of work as not changed much. Using this information we decide if we can add or drop some stories to reach the Sprint goal without pushing something half baked. 

When we have around 3 days left (108 dev hours) we kind of GUESS how many stories we can comfortably finish based on this information. And this guess will change for each team based on how they are VALUING their stories collectively. 

I agree with Tim in that doing all of these calculations against an estimate is just a bit too much. It’s a best guess, no matter how mature or educated a team is; it’s still an estimation and not a fixed value. Therefore trying to calculate it out just seems like a waste of time.

 

True! I should not have explained our little practice of learning what our story points ended up as hours (explained why in above post). We basically use the story points (per hour) derived from our refinement sessions and try to estimate how much we can do in each sprint knowing that our estimates will be less fluctuating as we progress like you just explained above. The calculation I posted in my first post is still the way we estimate. Based on how many point we did in how many hours (points/hr) which is the constant we want to meet or improve, we will estimate how many pints we can do in next sprint which is

Points estimated = velocity X (hrs available in next sprint)

While calculating velocity (if you are decided to use it) does any one consider the number of hours in their calculation?

For example if half of the team is off for some reason for the next sprint and the number of story points delivered were 20 instead of 40, would you consider the velocity as the same or different?

My first post is simply addressing this and we are doing pretty good forecasting how much we can do and meeting what we forecasted without stressing too much. I might have explained this with too many numbers/examples, but the idea is pretty simple.

Points per Hours and NOT Points per Sprint. 

I suppose there is some benefit (as outlined by Uma) to measure the actual time a PBI took, to give the team some insight into the accuracy of their estimating.   However, I still maintain that much of the time-based estimation and measurement is not needed, and is wasteful effort.   Just because a tool provides a capability, does not mean that it must be used.   ;-)

This is my approach with my teams, and it has worked very well for me and the teams I serve:

• People naturally gravitate to rating things across a 5-value range.   A smaller range does not provide enough options, and a larger range makes it more difficult to differentiate real value differences
• Case in point: think of the last time that you were asked to rate something on a 10-scale.   Did you clearly know what the difference was between a 6 rating and a 7 rating, or a 2 rating versus a 3 rating?   Think of the times you were asked to rate something from 1-5 stars.   Would your job have been easier if you had more or less stars to rate with?
• When asking teams to relatively estimate, you're really just asking them to categorize items into one of 5 categories (extra small, small, medium, large, extra-large).   Whether they prefer to use story points, or t-shirt sizes, or any other method (animals, cars, etc), they're just placing items into one of 5 categories of size
• A side-benefit to teams naturally gravitating to using a 5-scale is that it may be possible to normalize estimates at a program level, even when teams are using different terms or values (1-2-3-5-8, 5-8-13-21-34, etc)
• I have asked teams to create tasks for items, as it helps with item understanding, but I do not ask teams to provide any time-based estimate for those tasks.   In my opinion, the value around task-based time estimates is not supported by the effort needed to develop and track them
• And that's it.   Lightweight and simple.   The accuracy using this method is acceptable (and improves over time), and there really isn't much ROI returned asking teams to provide more granularity or detail
• Also, I do ask my teams to consider their capacity each sprint during Sprint Planning, as their availability may dictate how many story points are comfortable for the team to forecast.   Again, in my opinion, this lightweight approach is preferable to performing calculations in an attempt to promote "exactness" with team estimation

Just because a tool provides a capability, does not mean that it must be used.   ;-)

Point noted. We really need to stop over engineering this estimation I guess !

@Uma. I have gone through the video links which were very helpful to me at least start with some base. Because estimation topic is always confusing due to below probabilities was not able to understand exactly which is better and why?

I just saw that multiple discussions were happened after my last comment.

I am trying to clarifying my understanding once again.

What I have started to follow is estimating the user stories in user story points but the subtask will be in hours. Do we even need to estimate subtasks as well in user story points?

Addition of total hours of subtasks in hrs helps me to justify the capacity of user story points which we can pickup for first sprint

e.g. 

User story 1 - Story Points -3

                                    Subtask1 associated with user story 1 -> 12hrs

                                    Subtask2 associated with user story 1-> 15 hrs

User Story 2- Story Points -5

                                Subtask1 associated with user story 2 -> 15 hrs

                                 Subtask2 associated with user story 2 -> 19 hrs

User Story 3- Story Points -8

                                Subtask1 associated with user story 2 -> 20 hrs

                                 Subtask2 associated with user story 2 -> 22 hrs

   Then it helps me to understand total number of hrs required to complete two user stories which is (12+15+15+19+20+22=103 hrs)

Now assume that my weekly capacity of 7 team members with only 2 potential hrs per day is 7*2*5=70 and I have one week sprint.

Then it will help me to understand which user stories which we can pick-up.

e.g. Since I have capacity of only 70 hrs then I will just consider user story 1 and user story 3 (27 hrs+42 hrs=69 hrs)

and my capacity is 70. This it helps me to understand how much work I can pickup for the first sprint.

I can understand then what is the use of estimating user stories in story points since these are not helping to decide how much user stories we can pickup based on the known capacity.

Are other colleagues saying not to estimate anything even subtask in hrs and we should estimates these as well in user story points? But then we need to take care that story points of particular user stories should match with summation of the user story points of the main user story.

And also how we can guess how much story point of work we can consider since we are just aware about the total capacity in hrs but total work to be done in story points.

I guess somebody told that we just need to guess something in first instance and it will be improved over the time in case story point is the only measure for user stories and associated subtasks.

Apologies, seems that need to clarify my understanding once again if I am doing it wrongly..

Thanks

Bina,

My suggestion (and my preference) is to document the sub-tasks, but not go through the added (and in my opinion unnecessary) effort of sub-task estimation in hours.

You have the relative estimate of each item.   No need to estimate the sub-tasks in the hope that they will somehow always roll up to a correct SP value.   If that is your thought, then relative estimation is a waste under that approach.

You also have the calculated hour-based sprint capacity of the team.   Get a few sprints under your belt, and evaluate how many points the team is completing each sprint, and what their hourly capacity was each sprint.

Then have the team and PO plan the next sprint, using those metrics as guidelines for how much to forecast.

To start with the first sprint, just ask the team to make a forecast based on their best guess, and go from there.

Again, my advice is to not over-complicate it, and to treat estimates as guesses based on the information at hand.

Thanks a lot Tim! Sorry for the delayed response. I logged in after long time.