Contents
Set Yourself Up to Succeed- Establish Capacities
- Count on Success
- Review Stories
- Assign and Estimate Tasks
- Check Capacities
- Make a Formal Promise
Set Yourself Up to Succeed
In discussing the Agile Performance Standards, I explained the reasons FuSca™ emphasizes predictability. Usually when a team is struggling to deliver on its promises, there is a very simple reason: It is over-promising. The members pull too many stories into their sprints, without meaning to. In short, they set themselves up to fail.
Avoiding this consistently comes down to one simple principle played out in various ways. As you decide what stories you will put into a sprint, be conservative at every step. Seek out reasons to lower the time you think you have available for project work (your capacity). Hearing the slightest doubt, raise the time you think a task will take. Add any task you could reasonably need, not just the ones you know you need. Create tasks merely as reminders that you need to do them, even if you only apply 15-minute estimates to them. Shoot to fill 80% of your time, not 100%. When choosing between two possible estimates, if the team can’t reach consensus, use the higher number: When someone says a task will take “five or six hours,” enter “6” in the tracker.
I’m not saying to put ridiculous numbers on everything. But remembering Murphy’s Law,[1] you should assume the worst that is likely to happen, with the expectation that you will over-estimate the work. Humans have a built-in bias to underestimate tasks, and psychology research shows that people routinely think they will have more free time at a future point than they end up having. Over-estimate everything instead, and you will complete everything—often with no time left, due to that bias! FuSca encourages advance work in the backlog when all sprint tasks are done, so any extra time will not be wasted. And over time you will get the estimates accurate enough to rarely complete any stories in the backlog, meaning your Sprint Plans are even more accurate.
You can always deliver more work than you commit to. So don’t commit to it if there is any reason for doubt. That is how you “under-promise and over-deliver.”
Establish Capacities
We Can Only Do So Much
Comparing task estimates to individual team member capacities is one of the biggest differences between FuSca and other approaches to Scrum, most of which use story points instead. This technique has two advantages for new Scrum teams: It prevents the team from setting itself up to fail by taking on too much work, and at the same time reassures doubting managers that the team is working at full capacity. (For more reasons, see: “Why do we have to estimate tasks?“)
Over time, as a story velocity gets established and trust levels rise, the team is welcome to experiment with dropping any kind of estimates. Individual capacities are like training wheels on a child’s bike. They help the kid stay upright and on course until able to ride well enough to take them off.
What’s Your Week Like?
“There are,” the saying goes, “only so many hours in a day.” Until you stop to calculate how many there really are in a business day, you may be surprised to learn how small that figure is. “Capacity” is the number of labor hours each team member thinks that individual can commit to sprint work over the sprint period. A realistic capacity commitment is the first line of defense against over-promising in a sprint. Part of the Facilitator’s preparation for a Planning Ceremony is to calculate the “base capacity,” the maximum number of labor hours available to any team member during the sprint. The members will subtract their personal time constraints from that number to identify their individual capacities.
Base capacity starts with the standard work week. In the United States, 40 hours is considered standard, based on a law that actually only limits hourly workers. This figure may not apply to your team, however. First, obviously, you may be based in another country with a different standard. As of this writing, 35 hours is the standard in France, again for wage workers legally. Also, some industries work with alternate schedules like “three twelves,” where the person works three twelve-hour shifts in a week, and that is considered full time. For them, base capacity starts at 36 hours. On the other hand, some organizations openly state expectations that salaried people will work 45 or more hours per week.
Most organizations say they want people to have a healthy balance between their work and personal lives. This isn’t just a question of ethics. We know from studies that working long hours erodes productivity (output per hour); reduces quality, which further reduces productivity because you have to backtrack to fix things; increases sick leave; and raises the odds of workers quitting. That is the evidence supporting this principle of the Agile Manifesto: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Unfortunately, most organizations make only feeble attempts to plan work in a way that facilitates that healthy balance, if any. One of the unusual benefits of FuSca, I think, is it makes extremely clear when the enterprise is asking more than can be accomplished in 40 hours, as you will see. At the same time, there are several parts of the system that make “sandbagging” or “social loafing” difficult, meaning managers have evidence the teams and individual members are working as hard as they can.
Sometimes overtime, paid or not, cannot be avoided, even in Agile. Unexpected problems will at times blow your estimates out of the water, requiring overtime to fix emergencies and leaving stories unfinished in the sprint. That’s okay! The point to that Agile principle is to prevent this from happening routinely, as is often the case in waterfall projects.
Get Real about Your Day
Nobody actually works eight hours in an eight-hour day. Think about all the activities that take place during a normal workday but do not contribute directly to output. These differ depending on the type of job, but include:
- Snack, coffee, water, and bathroom breaks.
- Time lost to switching among tasks.
- “Hallway” meetings and extended online chats about general topics related to the business.
- Unplanned tasks such as help provided to colleagues not on your team.
- Personal phone calls that must be made during the workday, like appointment-setting and urgent family business.
- Socializing, some of which is not a bad thing for productivity if it builds understanding among members.
We’ll address the time for Scrum ceremonies and other scheduled meetings below. My point here is, the “eight-hour workday” in reality is more like a six- to seven-hour workday in terms of actual meeting and task time. As you start with Scrum, I suggest you assume a six-hour labor day for sprint work. Per the theme you have recognized in my advice by now, once you are delivering on your commitments well, you can reduce the buffer time this adds by switching to seven-hour days if you wish.
Laboring Away the Hours
This leads to a term I used before without defining it fully. By “labor hours” I mean time spent swinging a hammer, tapping at a keyboard, or in meetings specific to chosen tasks. It is not “clock time,” the total time a task or process might require, also called “duration.” As an example, there are tests engineers can run on a computer without constantly watching them. Say that:
- They take 30 minutes to set up a test.
- Once they start the test, it runs on its own for 75 minutes, during which they can work on something else.
- Reviewing the results and reporting those to the team only takes 10 minutes.
The “labor time” is 40 minutes, or two-thirds of a labor hour (30 for the set-up and 10 for the review). But the clock time is nearly two hours (40 minutes labor time plus 75 minutes “run time” for 115 minutes total):
In estimating tasks, we use labor time. The QA engineer in this example could work on another sprint task during the 75 minutes of run time (or do nonsprint work).
I recommend rounding all time to the nearest quarter hour, lest you drive yourself crazy tracking things to the closest minute. The engineer in this example would round up from 40 minutes to estimate the task at 0.75 hours—or better, if things sometimes go wrong, a full hour.
Address Teamwide Hits to Capacity
Labor time disappears from many work weeks before they start. Countries have national holidays. Some firms in the U.S. shut down the entire week between Christmas and New Year’s Eve. Most organizations will have the occasional meeting everyone is expected to attend, sometimes called “all-hands,” often at multiple levels: company, department, and group. All of these need to be removed from the base capacity for the sprint, since the team can’t use those labor hours for sprint work.
Every week, the team will spend time in sprint ceremonies. These contribute to the sprint’s success, yet reduce time available for work on individual tasks. Removing the ceremonies from base capacity prevents the team from “double-booking” that time. No stakeholder or team member can blame ceremony time for the team not meeting its commitments, because the commitments were made with the meeting time in mind.
People new to Scrum sometimes balk at the amount of meeting time, in part because they perceive it as reducing working time. The ceremonies are important to a team’s long-term productivity, and are the key to providing all the larger time-saving benefits of Scrum. These benefits require only a small portion of the sprint. As shown by the white part of this pie chart, around 90% of your time remains free for other work:
By the way, disciplined waterfall takes a lot of meeting time, too, most of it in weeks of meetings before you even start development!
Establish a Base
Combining the sections above, you create your base capacity by starting with your standard work week and removing everything that will take project time away from the whole team. Before each Planning Ceremony, as a Facilitator, I update a plain-old text document to look something like this (created for a team using three-week sprints with no breaks between, and six-hour labor days):
I open each Planning Ceremony by showing this document to the team. I tell the team the base capacity is the maximum labor hours any team member can commit to the sprint without planning on working overtime (which the team should discourage per the Agile Manifesto). In the example above, no one should commit to more than 70 hours without a really good reason.
A developer requested permission to work extra hours from a team I had trained. She was a contractor paid by the hour and was going to India for three weeks during the next sprint. (Note that as a good team player, she scheduled her trip to coincide with the sprint cycle!) She wanted to make back some of the money she would miss being gone that long. The team agreed. She committed to 20 hours more than the base capacity and completed her tasks. But this is a rare case.
⇒ Steps: Calculate Base Capacity
Include Time for the Individual
Working from the base capacity, each team member must decide how many hours they can commit to sprint tasks. First each should remove any individual time off, remembering to use the team’s daily labor hours for the calculation. Taking two days off equals 12 hours from the base capacity for a team using six-hour days. A dental appointment for two hours technically translates to 90 minutes of work time (using the 6/8 ratio), though I find that most people just call it “two hours.” There’s no need to get overly picky!
The next question is, how much of their remaining time is each person supposed to apply to this Agile project? Under my “Desired Agreements,” everyone is dedicated 100% to a project. There are numerous reasons you may not achieve this, such as:
- The person may be split between project work and customer support or ticket fixing. “Planning for the Unplannable” outlines my preferred solution, which is using placeholder stories. A team that chooses not to use that approach should nail down a number or percentage of hours from the individual’s supervisor that belong to the team each sprint. Work with middle management if needed to ensure the supervisor understands that time is committed to the team and cannot be reduced mid-sprint except in a true emergency.
- A part-time worker would need to adjust her hours based on her expected schedule.
- Although I push each client to eliminate this situation as soon as possible, initially someone might be split among project teams. In that case, ask their supervisor what percentage of their time should be spent on each. For the team in the figure above, the answers “half-time” or “20 hours a week” would translate to 35 hours (50%) per team for someone taking no personal time off.
At this point in the Planning Ceremony, the Facilitator asks each person one at a time for their capacity commitments. Emphasize the word “commitments.” Tell people you recognize outside issues will arise in some sprints that prevent them from putting in the hours they expect to. Kids get sick and customers have emergencies. Most sprints, however, the team should be able to count on each team member putting in at least as many hours as they say they will.
Sometimes after I show the base capacity in the Planning Ceremony, I will see team members jotting figures as they calculate their commitments. Using the numbers from the example above, Sharma might write down:
Notice that Sharma started to figure her hours for taking her daughter on a two-day college tour using eight hours per day, then remembered to use six instead. Her boss has told her to handle certain kinds of complex tickets, so she is guessing she spends about 10 hours per week on those. Because the team is using three-week sprints, that adds up to 30 hours. Given all this and a dentist appointment, she commits to only 26 hours for sprint work, less than half the base capacity. Not only will a mature Scrum team accept her logic, it might push her to be more conservative. Does she average 10 hours a week on tickets, but often put in 15? Maybe she should take 45 hours out instead. (Or better, the team should start tracking that work as part of the sprint, per the “Unplannable” section.) Just as the goal of the team is to have a consistent velocity while staying productive full-time, not to maximize the story count every sprint, you should aim for a capacity you are pretty sure you can achieve.
This example provides a stark reality check, and let me add that it is based on many real cases from my work with teams. Without going through the exercise, the team has no rational way to explain to a stakeholder why it is not moving as fast as the stakeholder would like. The stakeholder is thinking “three weeks” equals “120 hours” of working time! The example exercise shows that based on logic and hard data, three weeks is really only “70 hours,” or 42% less than the stakeholder is thinking. And if Sharma was the only QA engineer on the team, you could explain the reason there is a QA bottleneck this particular sprint is because Sharma’s theoretical 120 hours are actually only 26!
I strongly recommend any digital tracker you choose have a mechanism for entering people’s individual capacity commitments within a sprint, and comparing them to the total estimate for their tasks. It will make this valuable technique much easier to use. If you have that, you can skip the next section.
Create a Capacity Spreadsheet
If you are using a paper tracker, or a digital tracker without an individual capacity function, keep the commitments in the FuSca “Capacities” spreadsheet. To help you understand how it works, here are the columns:
- The team member’s name.
- Capacity per the previous section.
- Total of the member’s task estimates.
- Net estimated hours over or under the member’s capacity (Total – Capacity).
- Over/under as a percentage of capacity ((Total x 100) ÷ Capacity), rounded to the nearest integer.
A positive over/under is bad. I added some “conditional formatting” that turns a percentage cell red if the number is greater than 100. That makes it obvious when someone is over capacity. You will see the results of these formulas when we get to the step of checking capacities during the Planning Ceremony.
Count on Success
A second means of ensuring the team does not overcommit is to compare the number of stories in the Sprint Plan to the velocity, the number the team has historically completed. I have seen sprints fail when the members had capacity left but went over their velocity. I can’t explain the psychology in that; I just know it happens, because I have seen it, in teams using counts or story points. A team that has never completed more than eight stories in a sprint, but sets a “Sprint Goal” of 10 because that would complete a feature, is setting itself up for failure.
I should note here that the Scrum Guide and many Agile coaches recommend the team write a sprint goal that summarizes in words what the team is trying to achieve in that period. My first objection is that this may place an artificial constraint on the stories selected. The team could want to work on different epics in the same sprint, technical requirements not tied to any one epic, and so on. If it feels it has to be able to lump all the work under one label, this may cause it to make choices based on the process rather than the highest value. Even if not, it will waste extra time wordsmithing a line that in my experience does not make the team more productive—another inefficiency, and thus my second objection. You are free to add that step if you wish, but it is not part of FuSca, in which the term “Sprint Goal” refers to the number of committed stories.
When you are planning your first sprint, you have no velocity, obviously, so just limit yourself based on individual capacities. After the first couple of sprints, team members should question any attempt to go higher than the total number of stories accepted in any previous sprint. It is literally irrational to keep putting 20 stories into the Sprint Plan when you usually only get 10 accepted. Sadly, that example is based on a true story. I’m still shaking my head over the behavior, which by my definition amounts to lying to the Customer.
Once you are meeting the 100% delivery standard, you can use a “low average” as your goal. During the previous Retrospective or at the start of the Planning Ceremony, I negotiate a target number of stories with the team. If your team is averaging 12 stories per sprint, but in a couple of sprints it hit only 10, I would likely set 11 as the Sprint Goal for each subsequent sprint. Once a number is established, you can just repeat that each sprint until someone suggests changing it. The one obvious reason for doing so is that you are regularly completing stories that were not in the sprint—“working out of the backlog”—in addition to those that were.
Your tracking tool may have a means to enter your target and compare it to your current figure as you plan your sprint. Otherwise, just point out when the proposed Sprint Plan has gone over that Sprint Goal.
Velocity is not a “stop sign” you dare not go past, though. It is more of a flashing yellow light, telling the team to be cautious in choosing to do so.
Review Stories
Groom the Ungroomed
Especially during a transition to Scrum, there will at times be ungroomed stories near the top of the backlog when you walk into the Planning Ceremony. This is unavoidable if the Customer comes up with new requirements at the last minute. Unfortunately, it will add considerable time to the Planning Ceremony to have to groom a lot of stories. The next step of planning is to try to reduce the number of ungroomed stories at the top, preferably by moving them down in priority. The number considered “at the top” will vary, but basically try to get the ungroomed ones out of consideration by moving them below the Sprint Goal. For a goal of 9, see if you can move the ungroomed stories below #9. This decision must, as usual, be based on business or technical value, and the Team Guide has the final say. Those you can’t move, groom and then plan as you get to them in the rank order (“groom-plan” them, I like to say).
Should you find this situation occurring sprint after sprint, during a Retrospective consider steps such as holding a Grooming Session closer to the end of each sprint. There also may need to be a heart-to-heart talk with the TG or Customer about thinking through their needs more carefully after the mid-point in any sprint. A product manager who can’t say what work is important over the next five weeks[2] is not doing a good job of gauging customer needs or managing customer expectations.
In contrast, additional grooming of previously groomed stories is common. I once heard an Agile trainer say he thought that during the Planning Ceremony, a story should take two minutes at most: volunteer for the tasks, assign estimated hours, and move on to the next story. Maybe he was a better meeting facilitator than I am, because I have never been able to pull that off! Usually people have thought of new questions since the story was groomed that need to get talked through. In fact, that is the value of the “Grocery List Approach.” Take the time to address those issues as they come up while planning the story. It will pay off by preventing wasted time during the sprint.
Check the Blockers
Since a primary blocker of backlog stories is other stories that must be done first, you’ll want to check any blocked stories near the top of the backlog. Often a team realizes at this point that the predecessor story was accepted in the previous sprint, and thus the block can be cleared. Or maybe the action item listed in the reason was done, but the responsible person forgot to remove the blocker. As a Facilitator, I do some unblocking during and between sprints to save meeting time. Assuming the blocking reasons are clear, there’s no need to get team consensus on clearing the block.
⇒ Steps: Set Individual Capacities and Review Backlog
Assign and Estimate Tasks
Volunteering, Not Assigning
Now you are ready for the heart of the Planning Ceremony. Grab the top groomed, unblocked story, and pull it into the sprint. Software tools usually have a drag-and-drop capability, or you can open up the story card and assign the sprint manually. On a physical story board, simply move the notecard into the first row of the matrix in the “Sprint Plan” section.
There is no debate about which story to pull. It doesn’t matter whether team members think another story lower down should be done first. The Team Guide has spoken. You will work from the top down in the order shown, bypassing only blocked stories until everyone with a skill set required for a particular story is out of capacity.
Next flip to the tasks. You will not be “assigning” tasks. Individual empowerment and team self-organizing make this a volunteer situation. Someone who volunteers for a task will be more motivated to do it well, and feel a greater sense of control over their working life. Research shows lack of control creates job stress and reduces job satisfaction. There will be times when the team has no choice but to “volun-tell” someone to take a task. But always start with volunteers, and prevent others from naming other people’s names unless no one steps up. Remember that the team may be able to accomplish more high-priority stories if a junior member takes a task with the “obvious” person’s help than if the subject-matter expert takes all the stories she might seem best prepared to do.
Still, it is legitimate for anyone on the team to suggest that a volunteer is not the best person for a task. Possible reasons specific to a particular task in a particular sprint include:
- The volunteer is planning time off that, due to timing within the sprint, puts the story at jeopardy. If your QA person is out the last week of the sprint, someone else needs to do QA tasks.
- The volunteer does not have enough relevant knowledge or skill yet to both learn how to do the task and complete it within one sprint.
- Having a nonexpert do the work raises the risk too high due to the complexity of the story, whether that is technical risk or the odds of the story getting done within the needed time frame.
- The volunteer is needed for other more-critical stories. (Don’t let this become an excuse to avoid cross-training, though!)
In these and other cases, you will have to negotiate the task owner as a team.
In a paper tracker, just add the name(s) at the bottom of the task’s sticky note. Digital trackers will likely have a field for entering or selecting the name of a volunteer from a list of users. It may limit you to one person per name. There is a good reason for this approach: You cannot track individuals’ estimated hours versus their capacity if everyone’s hours on a shared task are lumped together. Depending on the task, that can make understanding progress more difficult as well. In these cases, for a task like a technical meeting that several team members will hold, create multiple copies of the task.
By the way, those guidance roles should be committing capacity to, and taking tasks in, each sprint. As stated before, these roles are part-time relative to a single team.
Estimate the Hours
With names on tasks, it is time for those names to name their hours. Ask each task owner to guess how many labor hours their task will take. This estimate is theirs to make, so prevent other people from suggesting numbers first unless the assignee asks for help.
Especially in the early sprints, folks may balk. “I have no idea,” is a common response, along with a range of incredibly obvious statements like “it varies” or “there’s no way to predict.” Yet every team I have worked with, including teams with customer support responsibilities, have gotten to the point where they threw down numbers with ease and delivered predictably.
Several tricks can make this easier:
- Ask the owner to think about a similar task they have done in the past and guess based on how long that took.
- Start with “ideal time,” how much clock time the work would take if that was the only thing to work on and they had zero distractions. Then apply the appropriate labor-day conversion. For example, the individual says it would probably take three-quarters of a day. Using a six-hour day, that converts to 4.5 labor hours. The shortened day and their individual capacity calculations have already allowed for distractions.
- Have them try using only Fibonacci Sequence numbers (1, 2, 3, 5, 8) or doubling (1, 2, 4, 8).
- For support or placeholder tasks, ask for a “worst-case average” as described under “Planning for the Unplannable.”
Challenge people when they say “four” or “eight” hours. When using six-hour days, you might ask, “By ‘four,’ are you saying ‘a half-day,’ or a morning plus an hour after lunch?” A half-day in this case is three hours, not four. To me this is another advantage of using shorter labor days. It forces people to think more critically about how long something will take.
If someone gives a number equaling more than two days, make them break it down further. In fact, limit tasks to one day or less whenever possible. The longer the time frame, the more “unknown unknowns” you may encounter and the more your estimate is a pure guess. Almost every time I have made someone do this, the total number of hours they ended up with was higher than the original number. In one memorable case, the person originally said the task was 24 hours of work (thinking “three days” and multiplying it from habit by eight hours each). After the Facilitator and other team members forced him to break it down, the final tally was something like five tasks and 35 hours—a 37.5% increase in time! The team decided the story was too large, broke it into two smaller functions, committed to one story, and met that commitment.
As with task assignments, other team members are welcome to weigh in on estimates. Encourage people whose body language suggests concerns to speak up. The chosen individual may be thinking the work will require steps it actually won’t, and be estimating too high. Or they may be forgetting about some technical challenges and estimating low. Harness the power of group decision-making to your advantage to provide perspective. However, the ultimate decision is the volunteer’s. No one should be forced to estimate higher or lower than they wish. Provide individual coaching before the next Planning Ceremony to people who consistently underestimate and thus fail to deliver their tasks.
Digital trackers will likely have a field for the estimate, though it may be hidden initially (meaning your admin will have to unhide it). For a paper tracker, establish a standard way of listing hours on the sticky note so anyone can tell at a glance which number is which. I would put the estimate in the bottom left corner to leave room for to‑dos and possibly actuals, like this:
The best digital trackers will automatically add up a person’s estimated hours across all tasks and compare them to the person’s capacity. Without that capability, you’ll need to ask team members to keep running totals of their personal hours to enter in your spreadsheet.
Massage the Task List
Often the process of assigning and estimating tasks triggers the realization some tasks are misnamed or no longer needed, or new ones are needed. Revise away! As mentioned in the section on grooming, the list was only a first draft at that point. You want it as accurate as possible now, to ensure people know what they should be working on and that their capacity comparisons are valid.
Although teams will resist adding stories during sprints (more on that later), it is acceptable to add, delete, or revise tasks during a sprint. However, try to get the list as “final” as possible based on what you know now, realizing new information comes up in the course of working on a story. The point is, don’t start out the sprint over-committed. Don’t set yourself up to fail!
Speak Up for Missing Persons
At some point someone available for most of a sprint will not be at its Planning Ceremony. The most common and acceptable reason is that they are on vacation that day. (A manager pulling someone into another meeting at that time is grounds for a frank discussion with the manager about priorities!) Encourage members to get in the habit of letting the Facilitator know about absences in advance. When that happens, the Facilitator should get the person’s capacity figure and any requests regarding which stories near the top of the backlog they wish to work on. During the ceremony, the team can “volunteer” them for tasks and enter initial estimates. But on the person’s first day back, the person can change the estimates and attempt to trade tasks with other members if over-committed.
This approach does not apply when someone is going to be out a significant portion of the sprint. Then you’re better off limiting their planned involvement to a few random tasks filling some fraction of their capacity. In other words, don’t make them the primary worker on larger stories. Otherwise you are introducing a risky number of “unknowns unknowns” by not having them involved in planning stories they are assigned to. They can use the rest of their available time helping teammates with sprint tasks and then working out of the backlog.
⇒ Steps: Get Input from Anyone Missing the Meeting
Check Capacities
Watch the Hours Go By
After you have added two or three stories, compare the total number of estimated hours for each person to their capacity commitments. A digital tool will likely make it obvious what percentage of their capacity is taken. Lacking that functionality, tell your members to keep track of their task totals, and the Facilitator can enter them into the spreadsheet each time you look at it.
When someone gets above 80%, start focusing on other folks. You don’t want to push up to full capacity if you can possibly avoid it. Sometimes you will need that person to help on other stories. Often they are the expert on a particular skill, and they will take small tasks in other stories to provide support to teammates or review their work. Also, during the sprint a badly underestimated task could break the bank if they start out at full capacity.
Once you realize someone is over 100%, you have three options, listed in order of preference:
- Trade tasks, either in the story you just planned or an earlier one, from the over-committed team member to someone with capacity left.
- Remove the latest story from the plan. You do not have enough capacity as a team to complete it.
- If the new story only puts the assignee slightly over capacity, they can volunteer to raise their commitment. This is dangerous. There is a reason they chose the capacity they did. I make the person explain why they think they can fit the work in, and never let someone add more than an hour consistently.
For practice, take a look at this example spreadsheet:
Sharma should take no more tasks unless the team deems it necessary, and then only one or two small ones. Tryst probably cannot take the lead on any larger stories. Mark needs to trade off one or more tasks totaling more than three hours, to Tryst, Kenyon, or Gina. If unable to do that due to skill sets, you need to remove the last story you put into the Sprint Plan with tasks for Mark—and consider cross-training in the near future to transfer some of Mark’s skills.
What you must never do is let someone lower their estimates in order to fit the tasks into their capacity. The work doesn’t magically get smaller just because you want to get it done. There is an old joke that the U.S. Army thinks if one woman can have a baby in nine months, two can have it in 4½. By the same logic, if you had reason to believe a task would take 5 hours, it is probably an 5-hour task whether you have 5 hours to spare in this sprint or not.
Now you see one reason why it is important to have 150% of your velocity groomed going into the ceremony. When one person runs out of capacity, it doesn’t matter that the next story by rank-order requires their involvement. You can’t do that story, and must move further down the list.
Remember the Sprint Goal
Also check at this point how many stories are in the Sprint Plan. Once you go over the Sprint Goal, warn the team (per “Count on Success” above). Facilitate a discussion about why it is or is not okay to go over the goal. As I said before, no matter how the hours are looking, you have to question the basis upon which a team thinks it can complete 12 stories this sprint when it has never completed more than 11 and normally does 10.
I mentioned already the one team I trained that had a hard time understanding it didn’t matter how many stories they thought they needed to do—they could only do so many stories. The members felt like they were not getting through the backlog fast enough, so they kept putting 20 stories in their sprints even though they had never delivered more than 14. It took several sprints for me to get across to them that wishful thinking was not going to speed up their delivery.
⇒ Steps: Build the Plan
Make a Formal Promise
Eventually, one or all of these events will occur during your Planning Ceremony:
- Everyone will be at 80% or higher capacity.
- People with capacity left will not have the skills to complete any of the unblocked stories in the backlog without the help of others who don’t have capacity to help.
- The team will reach a story count total at or above the Sprint Goal.
It might be that Paul and Ringo have 45% and 55% of their capacity left, but John and George are both above 90%. If the remaining groomed stories cannot be done by Paul and Ringo alone and require too much help from John and George, you are done. Paul and Ringo can get a head start on backlog stories, take on more of the team’s support duties—or maybe do some self-training so they can take more of John and George’s tasks next time!
When you hit this stopping point, take one last action to drive home that the Sprint Plan is a promise. Look around the room and say, “Do we as a team promise to deliver these stories in this sprint, barring something beyond our control?” Make sure everyone at least nods their heads, or on a conference call, name each person and ask for a verbal commitment one at a time.
Then declare the sprint officially started and fire your starter’s gun!
⇒ Steps: Complete the Plan
↑ The Sprint Process | ← Groom Stories | → Sprint to Success
[1] “If anything can go wrong, it will go wrong.”
[2] In the worst case of a four-week sprint with a Grooming Session the last week prior.