Expected sprint completion rate and load in scrum? [closed]

Question

Recently at work there have been increased focus on completion rate and load on the developers in our sprints.

With completion rate I mean, if we plan 20 user stories for a sprint, what percentage of these user stories are closed at the end of the sprint.

And with load I mean, if we have a sprint with 3 developers of 60 hours each, i.e. 180 hours for the sprint, how many hours worth of user stories do we schedule for the sprint.

So I am really interested in others experience with this, I guess this is something everybody working with scrum deals with.

My question is, what completion rate and load are expected/usual, and how are your team doing with respect to these parameters?

Answer 1

With regards to completion rate, this is usually tracked as the team's velocity. Velocity is the number of story points that were completed in the time-boxed sprint. Because a story is either done or not done (there is no concept of a partially completed story), this works out to reveal the same information that your completion rate percentage would. Velocity from the previous sprints is used to determine the velocity of your next sprint.

The next factor is your load factor. If you are also tracking some unit of developer contribution to the sprint, you can base this on velocity. This is just a relationship between the amount (or percentage) of time in your sprint a given individual contributed to the project. This is in contrast to "overhead" time (training, non-project meetings) and "out of office" time (vacations, holidays, sick time), and time supporting other projects.

I think both concepts are best demonstrated with an example with numbers. If you have a development team that consists of 5 people who contributed 100% to a sprint that completed 20 story points, you can use this data for calculating the expected velocity of the next sprint. Normally, you would simply plan your next sprint to have a velocity of 20 story points. However, if you only have 4 developers that are going to give 100%, you are effectively at 80% of your previous sprint. Rather than planning on completing 20 story points, plan on completing 80% of 20 story points, or 16 story points.

Of course, there are some assumptions made here. The biggest assumption is that all people are equal. Different developers have different strengths and weaknesses, and you might not be able to say that 1 person from your development team actually contributes 20% of the effort. You'll need to figure out, using historical data and expert judgement, how best to handle these cases. But I believe the general methodology is sound for calculating a next sprint's velocity based on the velocity of the previous sprint along with the amount of time a developer is dedicating to the project.

As far as expected and usual velocity and load, don't base your data on other teams working other projects - there are too many variables in terms of capabilities, productivity, and so on. Base your first sprint on your team's historical data coupled with expert judgement (preferably in groups). You can also use cost and effort estimation tools if that makes you more comfortable, but I haven't encountered or read about too many agile teams using tools such as COCOMO or SLIM for effort/cost estimation. If you don't have any historical data from previous projects, the judgement of the team should prevail. Within a few sprints, your velocity and load should normalize, allowing you to effectively predict the next sprint using your newly-generated historical data.

Answer 2

I think this is not a question of velocity, so much as over or under commitment to completing user stories.

During the Sprint Planning Meeting, the team makes a commitment to complete a certain set of user stories. At the end of the sprint, 100% of the stories should be complete, tested, and ready for deployment, if not deployed. IF the team has not completed all of them, they bit off more than they could chew, and they should use that knowledge when they make their next commitment in their next sprint. If they under committed, they should be able to add an extra story or two when the others are complete, but that should be the exception, not the norm.

Of course, in the first sprint or two, the team is at best guessing how much they can accomplish--so they'll probably over commit. Their velocity, once established, should give them a good hint as to how much they commit to.

Ultimately, though, it is a COMMITMENT!!! by the team, and they should be striving to meet it every time.

Answer 3

I find that a productive sprint will see about 5 hours out of an 8 hour work day as productive sprint work. Estimating time beyond 5/8ths immediately puts the sprint in a threatened state.

You have to figure time the developers spend in Scrum, other meetings, going to the bathroom, getting coffee and possibly production support or training (Continuing Education). It seems that with 60 hours per sprint, an ideal sprint length would be 96 hours or 2 weeks and 2 days.

My initial impression is that your average sprint in this scenario will probably see an average of 16 hours of user story work that is not completed by the deadline.

Answer 4

Our load is currently around 70% (where 100% corresponds to 6 hour days). It has recently been going up to about 85%. That just means that the team members are getting better at estimating the tasks (experience from previous sprints).

Our completion rate is around 50% (stable). In other words, an average story takes 2 sprints to complete. Here there is clearly room for improvement.

Answer 5

1) Generally, we take 6 hours as productive hours for a person day. It means that if a person works for a 4 weeks sprint cycle - his available hours would be 6 hours per day multiply with 20 days (taking off the weekends) which comes to 80 hours.

2) There is no hard and fast rule that - one SPRINT could take 20 stories and completed and next SPRINT will allow you to take equal or more number of stories to complete. We need to consider the complexity in developing each story. If the stories of the current SPRINT are more complex in nature to develop as opposed to last SRPINT - then we could take only less number of stories.

3) However, the team has to learn from SPRINT Retro meetings (1) whether or not the estimations on the stories to be improved (2) Is team over committing to take more stories than their capacity etc...

4) Bottom line is that you will take the stories and commit them if you are confident that you will be able to complete (leave apart the exigencies)