Contents

• Control Your Fate
  • Choose Daily Tasks
  • Stay Focused
  • Find New Work
• Record Your Status
  • Update Daily
  • Figure To-Dos
  • Block Early and Often
• Stand Up for 15
  • Prepare Burndown Chart (Non-Tracker Options)
  • Start in Minute 1
  • Review the Burndown
  • Answer Three Questions
• Toe the Goal Line
• Accept the Acceptable
• Support the Sprint
  • Facilitator
  • Team Guide

---

Control Your Fate

Choose Daily Tasks

What do you as a team member do during a sprint? Anything you want! Okay, that isn’t entirely true. Obviously you have to work on your sprint tasks. You get to choose which ones, however, and when you do them.

It is important to consider a couple of points when deciding what to do each day. First, you increase the odds of the team completing its stories when you initially focus on stories with:

• A lot of tasks.
• More people working on the story, relative to other stories.

Each work hand-off requires calendar time, since there is a delay between the next person finding out they can start and their getting free to do so. Hand-offs also create a “context switching” cost. This term comes from computer programming. It refers to making the computer switch back and forth between functions. Programmers try to avoid this because the computer takes longer to complete the overall task and wastes energy, and the program has more opportunities for errors. In humans, it is called “multi-tasking” and has the same impacts. Despite what people have convinced themselves to believe, a large number of studies have proven that switching your focus reduces the quantity and quality of work completed in a given time period. You can mitigate this risk by completing tasks other people are depending on as soon as possible, allowing more calendar time in case something goes wrong.

This leads to the second consideration. A waterfall project that falls behind early in the schedule almost never catches up. One estimate says this happens if the project falls behind only 15% into the total schedule! Applying that to Scrum suggests that if your team burndown is above the ideal line by Day 2 in a two-week sprint or Day 4 in a four-week sprint, your sprint is already in trouble. Whether the 15% figure is accurate or not, I know from having watched a lot of sprints that people who wait to start on their tasks until several days into it almost never meet their commitments. The best way to ensure the sprint gets done is to “front load,” as I call it. Start on sprint tasks as soon as you walk out of the Planning Ceremony.

I strongly urge team members I work with to calculate their average daily task commitment and spend that much time every day on sprint work. Say Tryst’s task commitments totaled 54 hours over a three-week sprint, and the team takes a day off between sprints. She would divide 54 by 14 working days to arrive at 3.857 hours per day. Wisely she rounds up to four hours, and goes the extra step of blocking out four hours per day from her online calendar. Note that no one is telling her which tasks to do during those four hours, or what times each day to do sprint tasks. And of course, she accepted those tasks in the first place. The more agile your team, the farther you get from micromanagement!

Some digital trackers make daily progress easy to show. Look for an option like “Personal Burndown Chart,” as one tool I’ve used called it. This creates an ideal burndown line for you, and tracks your progress against it the same way the Sprint Burndown Chart does for the entire team. I’ll talk more about that chart in a moment, and much of that guidance applies to your individual chart, too.

Stay Focused

You are also empowered regarding how to handle nonsprint requests for your time. You can attend meetings you are invited to after the sprint starts, as long as they do not interfere with sprint ceremonies, and you can still get sprint tasks done without working overtime. On the other hand, you now have the support of your team to get out of those meetings. You have the right to say, “I’m sorry, but I had not planned for that time when I made my sprint commitment. In the future please give me two (etc.) weeks of prior notice, and I will schedule it in.”

You can help someone, on your team or not, who asks for information or assistance. But again, sprint tasks must be your top priority. The occasional request taking a half-hour or less probably isn’t a problem. Another point to not filling 100% of your capacity during Sprint Planning is to enjoy this flexibility. Unfortunately, requests thought “quick” by the requester often turn out not to be. And multiple little requests can add up to a significant drain on sprint time.

Let me make this clear: Anybody is welcome to talk with anyone about anything anytime. However, to ensure you are prioritizing your customers’ needs first:

• Have the courage to tell people, “I’m sorry, but I need to get back to my sprint work.”
• When a “talk” turns into a request for you to do something, err on the side of creating a user story and putting it into the backlog for consideration during the normal planning process. You don’t have to turn down their request. Instead say, “I will be delighted to do that, but I’m supposed to run it through our system and get it in the next sprint to ensure we don’t overcommit.”
• Even if you agree the issue is an emergency, notify the Team Guide and/or Facilitator. You can go ahead and start the work while they decide with you whether it is a true emergency, and what to do about it or the Sprint Plan as a result.

When I talk about a disciplined approach to work management, this is a potential failure point. An actor doesn’t start chatting with an audience member during a performance (unless the script calls for that!). Bands only talk with the audience between songs. Athletes who stopped playing to talk to spectators would not last on their teams very long, no matter how good they were. In each case, the performers know they need to stay focused on their planned output. Why is a business team any different?

Find New Work

A frequent question from new Scrum workers is, “What do I do when I can’t do sprint tasks?” Sometimes you overestimate your tasks to the degree that you run out of sprint tasks before the sprint ends (in fact, this should be a goal for every sprint!). Sometimes people walk out of a Planning Ceremony knowing they have a lot of capacity left. More often, a member will hit the point where they are waiting on other people for every task they have left.

All of the above is normal. Even in a smoothly running Scrum team, everyone will hit this situation in one sprint or another. When it happens to you, remember that you have a share in the team’s commitments first, not just your own. Send a question to everyone, or ask during a scrum, whether anyone needs help with a sprint task or has a task they can hand over to you.

If not, you are free to do what you want. Obviously your manager may have things you could help with. You also might have an opportunity for self-training on new skills that would let you pick up more tasks. Indeed, if you regularly run out of work, that is a powerful sign you need to expand your skill set, for your sake and the team’s.

But you will usually add the most value for your customers and team by starting work on stories at the top of the backlog. With help from others in the same situation, you might even complete one before the sprint ends! In most cases, though, “working out of the backlog” will let the team delete tasks or reduce estimates on them during the next Planning Ceremony. Either way, you move the team closer to completing the project and add more value for customers.

This is another reason I recommended earlier that the team keep 150% of its velocity groomed. That way you can probably find a backlog story the team has fleshed out and will likely work on soon. This, in turn, reduces the chance that time you spend in the backlog will be wasted—that the deliverables you work on will not be used.

Record Your Status

Update Daily

On teams using a digital tracker, right before the Daily Standup, each member is asked to enter the status of their work:

• Mark each task you worked on with the correct state, if it has changed—When you have done any work on a task, it should no longer be in the default state (such as “Defined”) but rather a later state (“In Progress,” “Working,” “Closed,” etc.). The tracker will have a field for indicating the state. Obviously a task can be “in-progress” multiple days.
• Move the story, if needed—Some digital trackers will automatically move the story into the correct state based on your task status. Otherwise, you also need to ensure the story is in the correct state:
  • Until all tasks are complete—The state indicating the story is “in progress.”
  • When all tasks are complete—The last state before the one indicating story acceptance (“Closed,” “Completed,” etc.). In other words, if any task has been started but they aren’t all done, the story should be in the “In Progress” state, for example. When all tasks are “Closed” or “Completed,” the story gets moved to that state. It should not, however, get moved to “Accepted.” Only the Team Guide or requester, usually the Customer, can authorize that.
• Modify your remaining hours—The Burndown Chart is based on “to-do” hours. Estimate how much time you have left for each in-progress task, up or down, regardless of how much time you already spent on it. In effect, you re-estimate each in-progress task every day to keep the Burndown Chart accurate and help the team know where the sprint stands.
• Note any blockers—Mark the task as blocked if something is preventing you from getting a task done, and add the reason.

Those using paper trackers can do this before the scrum, but most people end up waiting until that ceremony. As they report on what they did the day before, they move the task sticky notes to the correct columns and update the to-dos in writing. When all tasks are complete, move the story card to that state and re-attach the tasks. Blockers can be indicated either in writing, or using a marker or sticky dot. I recommend using red to highlight that there is a problem. A paper task could look like this if it was blocked and the assignee expected to spend more time than estimated:

Yao moves the sticky note to the “In Progress” column on the board. He reports the task is blocked (“BL”) while awaiting input and jots that on the note. On a previous day, he had put in a half-hour and reduced the to-dos to 1.5 hours. He put in another hour before he was blocked, but that is not what the “1” on the note means. The team does not record actual hours. Though his original estimate was two hours and he has already put in 1.5, he thinks there still is an hour left after the block is cleared. More on that in the next section.

I’ve seen a lot of teams make the Facilitator do all the updates during the scrum. I prefer to have team members do it, for several reasons. First, the physical action can provide a subconscious sense of accomplishment that adds motivation. Second, it encourages people to do updates in real time or before the meetings, saving meeting time. Finally, if anyone misses the standup and is not in the habit of updating, the team won’t know the status of their work.

Figure To-Dos

In a perfect world, to-do hours would go down the same amount as the “actual hours” went up (whether or not you were tracking the actuals). Say you had estimated a task at eight hours, had worked on it three hours, and felt the original estimate was still accurate. Your to-dos would be five: 8−3 = 5. The Burndown Chart would reflect three fewer hours “to do,” though that might not be obvious depending on what other people did. (If the rest of the team added a net of three hours, for example, the chart would not change.)

Maybe the next day, after two more hours of work, you realize that during the Planning Ceremony you forgot about something you needed to do that takes an hour. Actuals went up by two, but to-dos only went down by a net of one (5−2 [+1] = 4). This adds a little bit to the Burndown, but that’s okay. The team needs an accurate picture of how much work is left. Of course, the opposite happens as well. The team member may realize the task is a lot easier than expected, adjust the to-dos lower than actuals would indicate during the sprint, and end up with actuals lower than the estimate.

Obviously, after you complete a task, the “to do” drops to zero.

Block Early and Often

Review “Blocks to Progress” for a detailed description of blockers. A technical issue, like lack of access to a piece of equipment you need and thought you had, is a clear blocker. Another might be that you are waiting for someone to complete their tasks. Don’t block for that reason right away; if everyone did that, most of the team would be blocked on Day 2 of the sprint! But if you are getting concerned that you are running out of time in the sprint to get your tasks done in a particular story, because someone ahead of you in the task list is not making enough progress, by all means put a blocker on your dependent task. Other demands on your time, like more support tickets than expected or a functional manager making you work on nonsprint tasks, are also legitimate reasons for adding a blocker.

Once a sprint begins, always put blockers at the task level, not on the story. The reason is simple: More than one task can be blocked at once, so a reason added at the story level might not tell the whole story.

More than one organization that consulted me had turned blockers into something bad. People were conditioned to feel they were making excuses, or worse, blaming another person if they declared a blocker. It took a good while in each case to eliminate that thinking. Blockers are just communication devices—a “hand wave” to get attention. Usually when a person is blocking you, on or off of your team, it is for a very good reason. In my experience, they usually just forgot about the request, or the dependency. By raising a blocker, you remind them of the urgency and obtain help for them from the Facilitator to take inappropriate pressures off of them. The mantra I ask Facilitators to push is, “Block early and often.”

For any blocker, in a few words note the reason somewhere on the task. That way anyone noticing the blocker doesn’t have to bother you unless they need details, saving you both time. Digital trackers often have a field for that purpose, and may automatically indicate the story is blocked when any of its tasks are.

⇒ Steps: Daily Sprint Actions

Stand Up for 15

Prepare Burndown Chart (Non-Tracker Options)

Use a Spreadsheet

Facilitators using a paper tracker, or a digital tracker without a burndown chart feature, will need to create a burndown chart and update it manually during the scrum. You can download our “Burndown Chart” spreadsheet, if you have a means of projecting it where your team holds its standups. Store it in a shared location so people substituting for the Facilitator can use it.

If you prefer a paper chart, keep reading. Everyone else, skip to “Start in Minute 1.”

Prepare a Paper Chart

This is a complicated set of actions to describe, and most are only needed once. So instead of cluttering up the “Steps” section, I will put all of the steps for creating and using the chart in the next few sections here.

The easiest—and most environmentally friendly—method is to use a white board, either a section of one that won’t get erased, or a smaller one you can hang or leave standing near your team. An alternative is a bulletin board with a grid made using tape, plus pushpins and colored string for the dots and lines in the next section.

To create the chart:

1. Draw or tape a vertical axis on the left and label it: “To-Do Hours.”
2. Hash-mark and label the axis with logical chunks of hours ending with the team’s total possible capacity (total number of members times the highest possible base capacity).
   Example: A four-person team on a one-week cycle might only have 96 hours ever available (base capacity of 24 times four people). Your chart thus could have 10 marks ten hours apart, with the axis rising a little above the top one. Obviously a 12-person team on a four-week cycle would have a far larger total and larger chunks.
3. Draw or tape a horizontal axis on the bottom and label it, “Sprint Days.”
4. Score the axis with one hash-mark per day in your cycle length, and number the marks.
   Example: If you are running a two-week cycle with one day off between each, you would have nine marks labeled 1−9.
5. (Optional) Use narrow tape to mark off a grid using the hash marks on the two axes.

See example charts under “Review the Burndown.”

Prepare the Chart for the Sprint

Between each Planning Ceremony and the first scrum of its sprint:

1. Add up the total number of estimated hours from all task notes.
2. Use one color of marker or sticky dot to mark that total on the left (vertical) axis.
3. Use a straight edge to draw a line from that mark to the last sprint day on the bottom axis.
   Note: This is your ideal burndown line.

Use the Chart

Hold your scrums in front of this board and:

1. As people update their to-dos, calculate and jot down their net changes across all tasks.
   Example: Sharma closed one task that had 2 to-do hours, but raised the to-dos on another from 3 to 4, for a net change of -1 (-2 +1 = -1). You note, “-1.”
2. After the last person reports, total the net change numbers you wrote down.
3. Apply the total net change to the previous day’s to-do total.
   Note: The new total could be higher, for example if a task was added.
4. Mark a dot in the current day’s column using a marker of a different color from the ideal line.
5. Draw a line from the previous day’s dot to the current one, using the same color as the dots.
   Note: A line chart is faster for a paper version than the bar charts shown below.

Start in Minute 1

The Daily Standup meeting or “scrum” is one of the simplest elements of Scrum, yet I regularly see it go wrong. Granting there is no “wrong” way to do Scrum, there are many ways to have these meetings go longer than intended and waste somebody’s time every day. The method I use aligns with most Scrum methods and books I’ve seen and with small-group psychology; achieves the intended goals; and minimizes wasted time.

Start the meeting on time by applying the “absence equals consensus” rule ruthlessly (if you have implemented it). A meeting that starts five minutes late every day will waste nearly a half hour of labor time each week for each person who shows up on time (5 days x 5 minutes = 25 minutes). Start on time, and people will adjust their behaviors to get there on time. For virtual meetings, set up a recurring Web conference at that time, and log into it before the meeting time to deal with the occasional connection problem.

If people are late, they miss out on other members’ reports, which is the tardy person’s problem. Have them give their report, and if they need information from someone else, they’ll have to track it down themselves after the meeting (or check the tracker). Ask anyone who misses the entire meeting or arrives after it is done to send a report by e-mail to the whole team.

As the name of the meeting implies, in collocated teams everyone physically capable of standing should do so. This helps to prevent meetings from dragging out. Choose a space large enough to accommodate everyone in a circle or oval, including anyone in a wheelchair or otherwise needing to sit due to physical issues. Virtual teams that can gather in separate conference rooms should do so instead of dialing in from their desks. Of course, if the team is mostly individuals in separate locations, there is no need to insist on standing!

Emphasize that the reports are given to the team, not the Facilitator. The Facilitator is not the boss, and the entire point to the scrum is for members to build accountability to each other. I have several tricks to make this clear in face-to-face meetings. First, I repeat that verbally as needed. Second, I will rudely refuse to look at the person reporting, and sometimes look around the circle. In person or in phone meetings, if someone refers to me specifically on something that should be addressed to the team, I will gently correct them right then: “Don’t apologize to me—the whole team is affected!” Finally, when an absentee sends an e-mail report directly to me, I will send it to the entire team with the sender copied. In a separate e-mail I will remind that person to send the report to the entire team in the future. Creating an e-mail distribution list of the current team members, if your e-mail system allows such, will make this easier for everyone.

Review the Burndown

The Facilitator starts the meeting by showing the team the Sprint Burndown Chart and mentioning any concerns (unless using a manual-entry chart, in which case this must wait till the end). What you want to see is bars below the ideal line and dropping roughly in parallel with it, like this:

A bar above the line as shown on Day 3 below is a concern, but may have a good explanation:

This could be due to a task somebody added or to-dos that were adjusted upward on existing tasks. Ask the members to mention the reason why during their reports. Remember that these actions are not only valid, but should be encouraged. They maintain an accurate picture of sprint progress, enable early warning of potential problems, and provide data for future estimates. If the team is making good progress, the bars will drop back below the line in two to three days, as shown starting on Day 5. (Note that some digital trackers will automatically adjust the ideal line to account for the new hours, unfortunately.)

On the other hand, just because bars are below the line, that doesn’t mean all is well. If the bars stop dropping or level out—that is, if they start trending toward the ideal line like this next chart—find out why. When there’s no clear reason, warn the team members they need to pick up the pace even though they’re still below the ideal line.

The worst-case scenario is bars below the line and not trending in the direction of catching up, as in the final example. This means the team will not complete all of the stories without extra effort:

This burndown results from one or some combination of these issues:

• People not putting in enough time on sprint tasks (not “front-loading”).
• People having to add a lot of tasks or to-do hours because they did not groom or estimate well.
• A major problem (risk) people did not anticipate, usually a dependency not identified earlier and now a blocker.

In this scenario, ask the group to address whether they are keeping up with their personal burndowns. For any who are not, ask “what is preventing you”—notice my nonaccusing language—and whether a blocker should be applied to help them get back on track. Any member can ask these questions, by the way: It is not the Facilitator’s responsibility alone to hold others accountable and find ways to help.

Answer Three Questions

Next move to individual reports. Either go around the circle from the Facilitator or have someone volunteer to go first each day and rotate from there. For virtual meetings I start with different people and switch up going forwards or backwards alphabetically, so everyone gets picked first on occasion. In either case, if you have a digital tracker with this feature, I find it speeds up the reports when you can open a list of tasks by the individual for people to refer to. Have each person say only:

1. What sprint tasks they worked on since the last sprint meeting.
2. What sprint tasks they intend to work on before the next meeting.
3. Any blockers they have.

The phrase “since the last sprint meeting” means on Day 2 of the sprint, you report on work done since the Planning Ceremony. On and after Day 3, it will be work done since the previous scrum.

Notice the emphasis on “sprint tasks.” During the scrum, the team doesn’t care about work not listed in the Sprint Plan, unless that work is preventing sprint work and thus is a blocker.

The Scrum Guide and some coaches have moved away from those three questions, but I believe that destroys the psychological power of the Daily Standup. The scrum is most effective as a commitment meeting, not a status meeting. One day, each member has to say what they intend to do on the team’s behalf; the next day, each has to say whether or not they did it! This builds accountability among the members to each other, and provides a safe avenue for communicating problems within a day or less of their arising. Status is reported via the tracker, not the meeting.

Your biggest challenge will be keeping people from detailing what they are finding… cool shortcuts they developed… problems they are running into … questions they have for another member… in short, the status of each task. To keep this meeting short and on task (pun intended), allow no more than a brief mention of any of these and then interrupt the person to keep them to the three questions. Again, anyone on the team can do that, not the Facilitator alone.

That’s not to say further discussion is impossible. After all, Agile encourages “Individuals and interactions over processes and tools!” Hold off on that discussion, though, until after everyone’s reports. At that point, I will say, “Scrum done.” Then I ask, in this order:

1. “Is there anything anyone needs to tell the whole team?”
2. “Are there any technical discussions needed, and if so, who should be involved?”

After the first is discussed, everyone not needed for #2 is allowed to leave or drop off the phone, though they can stay if they want to. This is also the point at which the Facilitator can begin addressing any blockers with affected members (per “Tackle the Blockers” below).

Some coaches refer to this discussion as the “16^th Minute.” I refer to that as “cheating.” There is a reason the scrum is meant to last only 15 minutes. Making people stand around listening to a discussion when they planned to do something else is disrespectful to their time, and if they don’t care about the topic, it wastes time and goodwill. Stop discussions involving the whole team that threaten to go beyond 15 minutes, and have the interested party set another meeting people can schedule around and prepare for. Sometimes the topics are appropriate to grooming or a Retro instead.

Use of a code phrase like “scrum done” will become a self-enforcing habit over time. I love it when a team member gets asked a question not relevant to the three questions, and after an awkward pause they say, “I’m waiting for ‘Scrum done!’”

These techniques combine to save time and reduce resistance to attendance. I’ve had meetings of 15 people last as few as eight minutes consistently, and no one has ever complained about them being too short! You should always be done with the three questions no later than 15 minutes after the start of the meeting. If the meetings go long with some regularity, it is a problem. At the very least you are being undisciplined. In worse cases, the team is not doing a good job of grooming, such that it is making decisions mid-sprint that should have been final by the end of the Planning Ceremony. Bring it up in a Retrospective to analyze what is happening and decide how to fix it.

⇒ Steps: Daily Standup

Toe the Goal Line

One of the great misconceptions about Agile is that greater flexibility means total flexibility. Customers sometimes get in their heads that they can make the team change gears whenever they want to. This is a great recipe for never getting anything done. An analogy I use in trainings is a trip by car. True, one of the reasons for a road trip is to have fun with no particular destination in mind. A project, though, is a trip with a relatively fixed destination. You can decide to take a different route than you planned on, to a different part of the intended region. Keep changing destinations radically, though, and you will never get anywhere.

This leads to a critical rule in Full Scale agile: No scope may be added during a sprint. You may remove stories that are no longer needed. You may revise stories with the Customer’s agreement—ensuring they still know what to expect at the end of the sprint—as long as the change does not add labor hours. Team members may revise, delete, or even add tasks if needed in order to meet the Acceptance Criteria. (Tasks are steps to achieving the scope, not scope themselves—members may not “gold-plate” the deliverable with functionality the story did not anticipate.)

You may not, however, add stories or make them bigger. The tradeoff we make with the Customer is this: If you agree to only change our direction at the start of a sprint, we promise to deliver everything we say we will almost every sprint.

This is another situation that requires discipline. When a requester:

• Asks the team to do a different story partway into the sprint, but still wants the stories already in the sprint done—I recommend your answer be, “Yes, we will be glad to do that, in the next sprint. We can only promise to complete the stories we commit to if you agree to only change direction on us every (2, 3, etc.) weeks.”
• Insists the new work must be done immediately—Determine if it is a true emergency. By that I mean, a customer reports a critical bug, or a manufacturing line has stopped, or an internal information system has crashed. An executive who needs information for a routine report is not an emergency; it is their fault they requested it late, and they need to take accountability for their mistake. A test a team member’s buddy forgot to run is not an emergency. A last-minute promise the Customer made outside of the planning process is not an emergency. Get the picture? Not a real emergency—hold your ground.

When it is a true emergency, negotiate with the Customer to determine which story or stories may be removed from the Sprint Plan. The team should not feel punished, or the performance data thrown off, because the team is doing the right thing! See “Planning for the Unplannable” for suggestions on tracking and reducing the impact of these events on sprint delivery.

• Asks a team member to do something else during a sprint, sprint-related or not—That member should ask them to speak to the Team Guide or Facilitator. The TG or Facilitator should follow the guidance in the previous two bullets.
• Decides they no longer want a story done—Simply remove the story from the sprint commitment without adding another story. Refer to “Find New Work” if this frees up time for team members.

The biggest objection I get to this approach is, “you have to do what the boss tells you.” In my entire project management career, and even further back, I have been able either to talk a manager out of an arbitrary change by showing them the impact to the project, or to talk them into reprioritizing the current work. A rational person presented with facts instead of a simple “we can’t do that” will respond rationally. Of course, if you have an irrational boss… well, you have a problem FuSca can’t solve!

These guidelines apply to team-desired changes as well. If the team adds stories, this adds complexity that puts the original sprint commitment at risk. More importantly, it gives the Customer valid grounds to ask why they cannot add stories when the team is allowed to.

Another objection I hear to not adding stories during a sprint is that backlog stories then do not count in velocity charts if completed. Or more generally, “we won’t get credit for it,” I’m told. First I would note again that the goal is to have a consistent velocity, not a maximum one. Over a number of sprints, the occasional added story is not going to impact the velocity figure mathematically. If stories are routinely added, by definition your estimates are off or you need to raise your velocity for purposes of the Sprint Goal.

Second, I would point to one of the principles of Agile: “Working software is the primary measure of progress.” As long as the work gets done, we don’t care about keeping a record of it. My preference when a story gets done in the backlog is to delete the story! If you get hyper about any other form of measuring progress, you open the team to insistence by stakeholders for other ways they want to measure it (usually including actual labor hours).

However, there is a pretty simple compromise if people are upset by the concept. Propose a process change during a Retro: The team will only add a new story into the sprint after the story is accepted. Work on it in the backlog, and if you meet the Acceptance Criteria, then you can add it to the sprint record—assuming, that is, that you completed all of your sprint stories. Otherwise the addition covers up the fact you did not meet the Performance Standard of 100% delivery.

Some Facilitators might gripe that this compromise is cheating. I don’t like the compromise, but it honors the principal of not promising something you can’t deliver as well as the principle of “pick your battles.”

Accept the Acceptable

When all tasks on a story are complete, and there are no open defects related to it, someone on the team should approach the requester for approval. It is not enough for the team to say a story or standalone defect is done. The requester must agree, unless they have granted the TG their proxy.

As discussed earlier, in most cases the requester will be the Customer. For more technical stories, it may be an architect or the TG. The primary developer on the story is the best person to make the approach, since they can help the requester review or test it, but the TG or Facilitator may need to drive the effort.

Although waiting until the Demonstration Ceremony to seek acceptance is, well, acceptable, the wise team requests it as soon as the story is done. That way if the requester does not accept the story, the team might have time to address any problems found before the end of the sprint, preventing story failure.

Recall from the discussion of Acceptance Criteria that the requester must accept or reject based on those criteria. The issue is not whether requesters like what they see. The only question is, “Did the team do what the Customer said they wanted it to do at the start of this sprint?” If the requester has changed their mind about the deliverable, yet agrees the team delivered what was requested per the criteria, the requester needs to give the team credit by accepting the story. In that case the team member and requester should create a new backlog story to make the requester’s modifications or—in the worst-case scenario—remove the newly accepted changes! An Agile team must be prepared to tolerate that the customer has changed their mind about the story as it was written.

Think about buying a car. A dealer ad or app makes you want a specific model. When you go take a test drive, however, you realize it isn’t exactly what you are looking for. Maybe you even decide you want a pickup truck instead of a sedan! Agility works on this principle. When people get what they asked for, that may actually trigger a change of mind. They get ideas about new features they want, or want the latest feature changed, or even decide they don’t want the feature at all. A Scrum team says, “No problem!”

However, if the requester does not agree the Acceptance Criteria were met, that’s different. They should not accept the story. The team failed in its primary mission, which was to meet the customer’s clearly stated expectations. Push the requester to give you very specific reasons. I got into the technology world through technical writing. I was always befuddled when a reviewer wrote a comment stating only, “This isn’t right.” Who in the world thinks that is helpful? Tell me what isn’t right about it, so I can fix it! You need the requester to tell you exactly what needs to change in order to make the story acceptable.

There is no need to dwell on the reasons the story failed with the requester. Instead, explain briefly what might have happened, and promise to fix the cause. Address that topic in the Retro. In most cases when there is a dispute at this point, either the Acceptance Criteria were not clear enough, or the team did not focus carefully enough on them and did something different.

Accepting stories as soon as completed provides other psychological benefits, in my experience. It communicates progress more precisely, builds momentum, and can get the competitive juices of the team going. “Success breeds success,” the saying goes. One of my teams achieved this near perfect burndown with the help of that approach[1]:

In case you are wondering about the lack of progress in the middle, note the dates at the bottom. This was a U.S. team, and that country’s four-day Thanksgiving holiday break came during the sprint! Because they had accounted for that in their base capacity, and front-loaded their sprint tasks, they still completed everything.

⇒ Steps: Story Acceptance

Support the Sprint

Facilitator

Coach the Team

During a sprint the Facilitator serves the same purpose as a “player-coach” during a sports game. That is someone who helps train the team during practices, and also plays regularly in the games. As the Facilitator, you run the ceremonies. During the sprint, though, you do any tasks you have chosen, and otherwise can only yell things from the sidelines when members aren’t doing what the team’s Scrum agreements prescribe. Okay, don’t “yell”… remind and persuade! I call myself a “professional nag” in this role. Examples actions include:

• Say something privately to members who are coming late to scrums, or failing to update the tracker beforehand.
• Raise questions when members seem to be straying from the Acceptance Criteria in their work.
• Redirect people to sprint work when they give too much attention to nonsprint work, intervening with outsiders including executives if necessary to protect the team member.
• Check the task lists of each story frequently and watch for delays. When an early task in a longer list has not yet been worked on partway into the sprint, contact the volunteer and ask if there is something you can do to help them get started.

Tackle the Blockers

A blocker should be discussed in the next scrum after it appears. Make sure it has been marked as such in your tracker. After the three-question reports, ask what you can do to help, or contact the blocked individual right after the scrum. Anyone on the team who can help—especially anyone who is holding up the work—should be in that conversation.

Your #1 priority as Facilitator is clearing blockers. That doesn’t mean you will necessarily do the work, however. You are responsible for making sure the blocker is cleared as quickly as possible. Empower the individual by asking what kind of help they want. Honor their request, but even if they want none, check back throughout the day to ensure progress is made. Otherwise be prepared to:

• Set up related meetings immediately.
• If necessary, skip any unrelated meetings—the blocker is your top priority.
• Repeatedly call someone who can help, and if that doesn’t work, that someone’s boss.
• Plant yourself in someone’s office.

Don’t back off until you are sure everything humanly possible is being done to fix the issue. And follow up regularly until the problem is solved.

⇒ Steps: Facilitator Daily Sprint Actions

Team Guide

The primary job of the Team Guide during a sprint is to refill the backlog by continuously applying methods already described (starting with “Gather Requirements“). Stay in touch with the Customer, constantly creating user- and market-requirement stories until the project is done. Identify and enter business and technical stories. Hold your Pre-Grooming Meeting.

Although anyone on the team can request story acceptance, the TG often becomes the primary driver. Encourage the requester to do the accepting as soon as the story is complete, and provide any information they need to do so (like the location of an updated prototype). When the requester is not available and won’t be at the Demonstration Ceremony, or defers to you because the story is too technical for them, acceptance falls to you.

Meanwhile, you may have to help the Facilitator intervene when people outside the team try to lay work on team members without going through the normal planning process. Sometimes they will approach you directly; often they will try to bypass you by going directly to team members, because they know you will (correctly) say, “No.” Encourage team members to tell you when that happens, but you usually won’t hear about it until the Daily Standup.

When that happens—and it probably will—contact the requester and find out if the issue meets the definition of a true emergency (per “Toe the Goal Line”). It usually doesn’t. In that case explain why the team will not be working on their request immediately, even if someone has already started, and work with the requester to create and prioritize a user story. When the issue is a true emergency, decide whether you need to negotiate removal of one or more stories from the Sprint Plan with their requesters.

As emphasized elsewhere on the site, outsiders should feel comfortable contacting team members directly about most issues. However, you are the funnel for all nonemergency work. All those other experts on your team should be creating user stories for any requests they get taking more than a few minutes to fulfill, and/or directing the requester to you.

Finally, if a team member has a question for you regarding an in-sprint story, make it a priority to answer quickly. My rule is to respond immediately to urgent requests within four business hours at most, even if just to say “I don’t know” and promise a time by which I will find out. Questions that may seem trivial to you are clearly important to them—quite possibly important enough that if you do not answer, you will find yourself named as a blocker in the next day’s scrum!

⇒ Steps: Team Guide Daily Sprint Actions

↑ The Sprint Process | ← Plan the Sprint | → Demonstrate Your Success

---

[1] Screenshot from Rally in 2012.