4

My team works in a 3 Weeks sprint, and accordingly we calculate the capacity of Team member based on his or her planned holidays and company Vacations.

But we cannot deny any unplanned / Sick leaves, Unplanned meetings and Training. Different Inter & Intra team communications which may be important for my own project or other teams. Knowledge sharing is an important core value of a growing organisation that encourages open cross team interactions.

Different Sprint Ceremonies also take some time of the team members during these 3 weeks. What points are important to be considered calculating the Capacity of the Team members considering they spend 8 hrs in the office.

4

The Scrum Guide says this on the things to take account of when determining the commitments for the next sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

The most important thing to take account of is the actual evidence of the work you've achieved in the past. The measure of how much your team can get done in an iteration is typically called Velocity.

It doesn't matter whether team members are there for 8 hours. It doesn't matter that sometimes there are meetings. We aren't individually interested in these things, and it's much better to directly measure the thing we do care about, our velocity.

Note that the Development team is responsible for deciding commitments (not the scrum master), and that performance is measured as a team, not as individuals.

While the Scrum guide leaves the "How" the development team estimations stories an exercise for the reader, most successful teams use something like Story points.

For example, lets say my team has a few stories of size (in points, left is highest priority) { 1, 5, 8, 3 }. If last sprint, we managed 6 points, the team knows to take on 1 and 5 only. If we managed 9 points, we know I can take on 1, 5 and 3. The thing powering the team's decisions is evidence from previous iterations. A "point" is not linked to any amount of time other than through our evidence based measure of velocity.

Teams that use hour estimates in practice don't make good use of velocity and therefore plan poorly.

So to summarize,

  • Estimate stories in points rather than hours
  • Measure the Velocity of the team and use that to decide how many points to commit to
  • Make sure the development team is making these decisions, not you
  • Thanks, for the response. Stories are calculated with Story Points. But at tasks level in practical scenario, hours needed to complete a task is to be shared with team & PO. Everyone is interested in the Man HOUR EFFORT. There has to be an expected time by when an activity would be complete and another person would pick his task after this. Thus, hours have be associated with a task. It is then the trouble arises, where a member assumes to complete a task for 6 hr. When it take more time due to Complexity, other priorities, some meetings. Thus, hampering the teams process. How to handle this? – Anurudh Singh Jul 22 '16 at 4:40
  • 1
    @AnurudhSingh Don't do that, it's a waste of time. Clearly you've not found it to be accurate (because it's overly precise), it sounds like an expensive thing to do (in terms of time) and it's based on the fantasy that new tasks won't be discovered. What value does it even provide towards the teams goal of delivering working software? – Nathan Cooper Jul 22 '16 at 9:06
  • "expected time by when an activity would be complete and another person would pick his task after this". This is a reasonable concern. The answer is however, to get better at collaboration and to continously make these sort of judgements (at stand ups etc) rather than relying on upfront planning. – Nathan Cooper Jul 22 '16 at 9:11
4

I'm deducing that your team uses story points for an initial estimation then, at the planning meeting, breaks stories into tasks and estimates them at the hour level.

First, some general suggestions:

  1. Never schedule 8 hours a day. Interruptions happen. Only schedule about 6 hours a day for development tasks.

  2. Make sure you're removing those planned days off from the team's capacity. Likewise, be sure to remove known meeting times from the capacity as well.

But you seem to know that already. You want to know how to handle unexpected absences.

  1. Leave some slack in your planning.

    We humans are really bad at estimating. Things usually take longer to do then we estimate they will. Leaving a bit of slack in your schedule allows you to absorb both the bad estimates and some absences. If the team does meet their iteration goal early, then they have some time to pay off some technical debt.

  2. Accept that any given estimate will likely be wrong and you won't always get all the stories done, even if every one shows up every day.

    Basically, don't worry about it. Take some time to remember that developers are people, that you're a person and not code generating machines. Embrace the uncertainty of software development and find ways to be flexible. Can we drop a story from this iteration? Joe got his tasks done early, can he pick up Susy's while she's out? Can we extend this iteration another week? Learn to be flexible (dare I say, agile) and react to the unknown with grace.

    So, you failed to deliver every story in the iteration? Big deal. It happens. Bring it up in the retro, let the team talk about why and how they can lessen the impact of unplanned days off. They'll have way better ideas than strangers on the Internet.

  3. Stop doing hour level estimation.

    It's largely a waste of time that generates a false sense of knowing, in my personal experience. Instead, use the historic number of story points completed as your team's capacity. In any specific instance, it will be wrong, but so will the hour level capacity planning. Sometimes they'll get more done, sometimes less, however on average it's a pretty good indication of how much the team can accomplish in an iteration.

    The goal isn't raw throughput of tasks. The goal is an iteration of working and valuable piece of software. Do the most important thing first, and you'll have that whether or not someone on the team gets sick for a few days.

4

TL;DR

Estimate your team's capacity as an aggregate range based on historical performance, rather than as a sum of the ideal hours available to each individual. Furthermore, you should carefully consider what you hope to accomplish with such a calculation, and determine whether a more agile approach to productivity and statistical estimation might not be a better fit.

Estimate Team Capacity

My team works in a 3 Weeks sprint, and accordingly we calculate the capacity of Team member based on his or her planned holidays and company Vacations.

In Scrum, velocity or capacity for an individual is never calculated. Instead, you calculate the projected capacity of the entire team based on empirical measures of past performance, and expect minor variations in individual or iteration capacity to even out over time.

More importantly, while you can use various techniques to estimate ideal hours available to the team, this will not give you good predictability regarding the amount of work you can do in a Sprint. Unless it's your very first Sprint, you're much better off using relative sizing (e.g. story points) and estimating how much work you'll be able to accomplish in any given iteration based on empirical data about how much work the team has been able to accomplish in the past.

Ideal Hours

Even if you choose to use ideal hours rather than story points, you would calculate a team capacity. For example:

  1. Make sure you include all elements of your Definition of Done in your definition of work.
  2. Assume a baseline of 4-6 hours of useful work per business day.
  3. Multiply by the number of team members.

So, a five-person team has 60-90 ideal man-hours available in a three-week Sprint. You could just stop there, and let statistical variation iron itself out.

As an alternative, you can apply a fudge factor to adjust for known issues in a forthcoming Sprint. For example, you might:

  • Reduce total capacity by at least 20% if a member of a five-person team is on extended leave.
  • Reduce capacity by 7-10% to account for a holiday in the middle of your upcoming Sprint.

Pragmatically, I tend to apply fudge factors for large potential drags on velocity, but generally ignore them for minor perturbations like a planned dentist appointments.

Solving Your X/Y Problem

It seems likely that your real problem isn't a lack of precision estimation, but rather than you are treating team members as individual resources and striving to optimize for utilization rather than throughput. While you didn't explicitly say so, the way your question is phrased at least implies that tasks are being assigned to individuals, rather than collectively owned by the team, and therefore the absence or reduced capacity of any member of the team can create bottlenecks or expose dependencies within your delivery pipeline.

Don't do that.

Instead, make sure that backlog items are owned by the entire team, and that the team is working collaboratively to complete stories rather than sequentially or in parallel. In addition, backlog items should be as independent of one another as possible, so that the inability to complete one due to resource or time constraints doesn't "halt the line" for other backlog items as well.

Even if you're not making the mistakes I just outlined, please take some time to really consider why you are trying to trace capacity metrics to the individual level, rather than taking the team-based approach that underpins most agile methodologies. You may be surprised to find that doing so is unnecessary, and even counterproductive, in many circumstances.

  • 2
    ++ for mentioning the utilization fallacy. – Nathan Cooper Jul 22 '16 at 23:29
  • Scrum team (Dev, QA, TW) have specific roles. Some tasks require specific skill sets and the respective member has to work on it. Thus, a task n Story would be assigned/owned by a person. Though few tasks could be reassigned during Sprint. Additionally, Stories are given Story point (say 8), this would split into 5 tasks assigned to 5 members. How could we ensure and Monitor, when a task (thus Story) would complete. The criteria for the same has to be there and easiest option is Hrs to complete a task with a DOD. How to Monitor & ensure team is working with right intensity in such a situation? – Anurudh Singh Jul 27 '16 at 8:55
  • 1
    @AnurudhSingh There are so many misconceptions in your comment that I'm not even sure where to start. You're basically violating most of the agile principles all at once. What you're describing isn't Scrum, isn't agile, and doesn't even make sense from a framework point of view. I suggest re-reading the official Scrum guide, and then asking specific questions about each individual problem you're facing. – Todd A. Jacobs Jul 27 '16 at 11:47
  • 1
    @CodeGnome, Thanks for your feedback. I do understand we have modified & diluted Scrum while we implement the same, and we are doing a Scrum BUT. I will proceed as per your suggestion and would share some other questions later. Thanks ... – Anurudh Singh Jul 28 '16 at 4:43
1

Try adopting the LEAN idea of 'waste'

Get the team to record their hours against tasks, meetings, admin etc so that you can work out exactly how much time you are spending on 'non work' tasks each week.

This will give you both an average percentage of 'waste' time which you can factor into individuals capacity AND enable you to identify stuff that you can cut out to increase capacity

-1

Rather than trying to plan for unplanned meetings, training or sick days, schedule a set of hours each day for team centered activities, such as:

  • pair programming
  • code review
  • integration testing
  • security testing
  • performance optimization
  • merging branches

In addition, create a reserve story which captures a percentage of each team members capacity each sprint to handle foreseeable action items, such as:

  • production bug fixes
  • research for spikes
  • build breaks
  • SSL renewal
  • Refactoring code
  • Updating documentation
  • Integrating retrospective suggestions
  • Planning for the next sprint

References

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.