Determining How Many Task Hours in Agile a Team Can Accomplish
Note from Mike… I want to welcome Jim Magers to the LeadingAgile team. Jim is doing a project with me in Minneapolis, and I asked him to join me here and share some of his experiences from the field.
Your team is new to agile.
So far, you’ve groomed and organized your backlog, defined your epics and features, and written some user stories. You’re pretty happy with the quality and definition around your acceptance criteria. The team has done some story sizing, and you’ve decomposed some number of stories into tasks and assigned ideal hour estimates to them. So, how do you know how many hours the team can take on to have a chance at a successful sprint?
Teams that I’ve coached have found this sprint utilization worksheet to be a useful tool for estimating initial team capacity, and most have continued to use it beyond the early phases of their agile development as they continue to tweak and improve upon their initial assumptions.
Remember that an ideal hour is an hour of work where one is able to focus entirely without interruption. My experience is that an agile team that has an average overall utilization of 65% is generally working pretty productively. That means that in an 8 hour day, a team member who is at 65% utilization is accomplishing somewhere between 5 and 6 hours of focused effort every day. But you may have team members who are more productive than that. Perhaps they work remotely and don’t get pulled into as many meetings or side issues and thus are more able to focus better on sprint work.
On the flip side, there are others don’t even come close to hitting the 65% goal. These may be new employees who are not yet fully trained, or maybe they routinely get sucked into having to deal with with customer or production issues.
And of course people take days off for holidays and scheduled vacations. All of this needs to be accounted for in order to be able to confidently estimate ideal hour capacity.
This worksheet assumes a two week sprint, or an 80 ideal hour starting capacity for each team member. Take your best initial guess at what you think the utilization will be for each team member, being as realistic as possible about their ability to focus on the work of the team for the upcoming sprint. In the worksheet examples, the utilization numbers I have assigned range from a low of 25% for Pete Hill to a high of 80% for Mary Doe.
Remove any hours off the top for planned vacation, holidays, or all day meetings where you know that the staff won’t be able to work at all on sprint tasks. Joe Smith, Tom Jones, and Brenda South are all taking time off during our iteration, and that is reflected in the “non working hours anticipated” row.
That then leaves us with ideal hours available, and after the individual utilization factor is applied we can derive ideal hour capacity for each team member, summed up to calculate total potential team hours available for the sprint.
While the group has 408 ideal hours available in the sprint, based upon these factors of utilization and time away from the real work of the sprint, the team should be OK to take on around 229 ideal hours of tasks.
If your team is mature enough to have established a consistent story point velocity, this worksheet will also give you a sense of how many story points you can handle in the upcoming sprint, based upon some level of increase or decrease relative to historical capacity. In my example, the time out of the office reduces the potential of the group by 15%. Since the team average velocity at full force has been running at 35 story points, that 15% reduction would result in a recommendation to take on 5 fewer points than they might typically sign up for.
Comments (12)
Dave Rooney
Hello Jim,
After a team has a 2-4 sprints under their belt, what would prevent them from using Yesterday’s Weather to determine how many backlog items to take into the sprint? In other words, if they completed 20 points in the previous sprint, only commit to 20 in the current one.
After all, completion of backlog items is what delivers value to the Product Owner, not the completion of tasks. It’s possible for teams to get hung up on tasks, and get into the unfortunate position of have 85% of the tasks complete near the end of the sprint, but not a single full backlog item.
My experience has been that slowly removing the focus from the tasks and placing squarely on the backlog items is more effective over time.
Hey Dave,
I agree that delivering backlog items is where the value is. But in my experience, new teams with no track record of velocity really benefit early on from breaking those backlog items into more granular tasks and being able to go into the sprint with confidence that they can complete the work that they are committing to. I’ve seen this tool help them accomplish that, and success breeds success. One team I just started working with has been claiming to be agile for nearly a year, but has never once successfully completed a sprint. This tool is proving useful in helping them figure out the right amount of work to take on and finish. Once they get their sea legs, they won’t need to rely on this as much.
Since most developers appreciate logical, analytical approaches, I’ve seen skeptical new team members buy into the work commitment when I’ve utilized this worksheet, and their buy in helps make the team successful.
Dave Rooney
Hi Jim,
Sure, I agree it can be useful for a team that’s just starting. Take the training wheels off after 2-4 sprints, though, when the team has a few velocity data points.
Reducing the lengths of meetings is also a way to get significant buy-in. :)
I’m generally of the mind that 2-4 sprints is not the right indicator. The right indicator is when the team gets good at thin slicing the user stories. Hopefully that’s in 2-4 sprints… but not always. If a team is using relative estimates, and everything falls into the 1 or 2 range… sometimes 3, I usually try to get them using story points only. When I still have 5, 8, 13… or God forbid, 20 on a backlog item… we are doing task breakdown. I’ve got to see incremental delivery in the sprint… I’d prefer incremental delivery of user stories… but I’ll take tasks if that’s all I have.
Also… the one thing that Jim’s approach does deal with is how to handle when folks are out. If we use yesterday’s weather, the team is left to a gut feel of what they can accomplish given the absence of the missing person. Mature teams handle this well… newer teams may not. So this is probably just a special case of the previous argument. Great conversation!
Dave Rooney
Hi Mike,
I agree completely with thin slices, and prefer that teams only use 1, 2, 3 or “too big” for estimation. My current client is in telecom, and there are legitimate 1’s and legitimate 13’s, although that’s improving over time.
For handling absences, the long-term average velocity should accommodate that. If you have 2 of 7 people away for an entire sprint, that’s another story, but using the average should normalize the slight variations in velocity.
I guess my view can be summed up by, “Don’t over-think it!”
Brian Sondergaard
Jim, nicely done. Hey! I think I recognize that spreadsheet :-)
Jonathan Warshay
The link to the worksheet is dead. Is the worksheet available elsewhere? Thanks!
Just fixed the link.
Dinesh
I want to create Capacity planning spreadsheet for each iteration. How do i use your (sprint utilization worksheets) , these all are xml files . Can you pleas help
Thanks
Hi Dinesh,
I’m not sure I understand your question. What are the xml files you mention? The link in the post points to an Excel file.
Kirk Bryde
Jim, like the idea of adjusting each iteration based on the capacity of the team (measured in hours and in % availability). I think the significant factors are (a) how many work days there are in the iteration – some iterations will have less days due to stat holidays; (b) the count of the members on the team – which fluctuates as members come and go; (c) % availability of each team member – 100% for full-time members, less for part-timers; and (d) significant absences of each team member – to the nearest half-day, due to vacation, illness, training, special assignment, etc.
However, IMHO I think you take this one step too far, by trying to estimate the % availability of a normal team member during a normal workday. What I’m getting at is that for full time team members, I don’t think you don’t need to estimate how much time might be spent checking email, attending corporate-wide meetings, water-cooler chats, or other time-consuming things that fill up a day.
The velocity algorithm already accounts for all these “inefficiencies”, so you don’t have to. That is, given an average amount of daily overhead for each team member in each iteration, the capacity of the team is consistent, so the velocity will also be consistent. i.e. You only need to account for the exceptions – not for the routine overheads.
Marta Zdanevych
Hello Jim,
I really like the way you put it here. I should admit that’s about how things worked when I was leading my dev teams :)
However, currently, I am working in a functional office and it has been suggested recently to plan our work in Jira based on two-week sprints. We also have a recommendation (requirement) to plan about 80 hrs of tasks for 2 weeks and avoid changes during “sprint”. The work we do depends on communication and meetings with other stakeholders, and every sprint there are some priority activities coming from the top that need to be accommodated to the packed schedule.
Do you have experience with ideal/real hours planning in the office type of work?
What are typical hours that make sense to be preplanned two weeks in advance?
If we do not measure velocity&capacity (we do not because everyone works with own scope, on own estimates) why would that make any difference if I change the tasks planned during the sprint or not?
What would you suggest to measure in office work overall?
Thanks a bunch
Marta