Groom Stories

Contents


Understand before You Develop

Grooming is a time for understanding. You don’t want to walk out of a Grooming Session wondering what a story is about or what the Acceptance Criteria mean. The story was not properly groomed if you get into a Planning Ceremony and someone feels the need to ask, “What exactly are we doing?” Or, “How are we approaching this?” (Although, it’s better to ask then than after the sprint is under way!) Each person is responsible for making sure their questions were answered. Speak your doubts. Don’t say you understand or agree with the story as written if you don’t.

Like much of the human experience, though, you can overdo it. Don’t tie yourself to one approach to a particular user story in advance if you don’t have to. Grooming is primarily about what needs to be done, now how you will do it in the technical sense. In deciding if a story can be done in one sprint, allow time for the questions that will come up while you are doing the work. To the degree work can be fun, Agile should enhance that experience. So long as the Acceptance Criteria and tasks to getting there are clear, allow yourself room to play with the implementation.

“You” in this discussion, and throughout these team-level sections unless otherwise specified, means anyone on the team. Often it ends up being the SM. The whole team is responsible for team and self-discipline, however.

Pre-Groom for Speed

Despite that last paragraph, perhaps the most powerful half-hour per sprint for improving team speed involves just two people. That is all the time the Customer and PO need to meet to efficiently ensure the team is headed in the right direction, and thus prevent everyone from wasting time. I call the process “pre-grooming.”

A sign of a healthy relationship between a Customer and team is that stories will be continuously added—the Customer is constantly identifying new requirements, and writes each as a user story or epic in the tracker (or at least sends it to the PO in the right format). If that is not happening, you may need to lengthen the Pre-Grooming Meeting to an hour or more. Regardless, the first step in the meeting is to create any new stories needed.

Next review the backlog and come to agreement on the story statement, acceptance criteria, and rank order of twice as many stories as the team is likely to deliver in the next sprint. Write the answers to any questions that come up into the body of the related story card, because other team members are likely to think of them. That’s it.

The reason this saves so much time is the same covered under “Follow the Format.” By making sure the two people most responsible for channeling customer needs to the team are in agreement, you reduce wasted time for the team. By resolving in advance many of the issues the team would otherwise raise while grooming, you save four or eight or 12 times the number of minutes required: one labor-minute for each additional member of the team.

Meet prior to the last Grooming Session of each sprint (or shortly before the Planning Ceremony, if you don’t do separate sessions). Your goal, again, is to have 200% of the team’s velocity pre-groomed. For reasons detailed in “Plan the Sprint,” this ensures the team can groom enough stories to keep it busy.

⇒ Steps: Pre-Groom the Backlog

Review the Order

Now you are ready for the whole team to groom. The first step in a Grooming Session is to look at the order of the stories in the backlog. The value and urgency of each story will make more sense to the team if members have the opportunity to question the Customer or Product Owner on the “why” of the order. However, team members need to understand this is not a debate. It is okay to ask questions that help you understand the order, and to suggest changes. It is not okay for you to argue about the order. Choosing the final rank order is one of the Product Owner’s unique duties, and the Customer’s input on user and market requirements carries the most weight. The team’s job is to fulfill the PO’s choice even if the team disagrees with it.

One reason to review the order is that it may make sense from the standpoint of business needs, but not so for technical reasons. For example, take a quality circle[1] tasked with improving warehouse operations. It might have a story to fix the forklift lanes in a section of the warehouse where there have been problems with near collisions. The team might realize fixing that one area could impact the flow of other forklifts passing by that section, and have a story further down the backlog for reducing backups in the main pathways. It could wisely argue to the PO doing that story first makes more sense.

Another example comes from the software world. A “quick fix” in one method could cause a ripple effect of problems in other parts of the code, so it might make more sense to tackle refactoring across related methods (and therefore stories).

In either example, stories may need to be reshuffled. And the needed story might not exist yet, because the need hadn’t occurred to anyone until they saw the more specific issue. But the PO has the final call; if he or she wants to stick with the original order, move on.

⇒ Steps: Review the Story Order

Ignore “When”

During grooming, forget about when the story will be done. The top stories in the backlog might not get done in the next sprint, for a variety of reasons, such as:

  • The order could change before your Planning Ceremony because the Customer or PO decides other work is more important.
  • A story can get “blocked” from going into a sprint because a technical problem arises, or you find out a key person outside of the team will not be available.
  • Just because a story is #5 and you usually get five stories into a sprint, that doesn’t mean the story will get into the next sprint. You might find out someone who must be involved in it has used up all of their capacity in the first four stories, so the team has to skip #5 to a story that does not require that person.

To repeat, grooming is about “what” and a little “how,” not “who” will do the work or “when.” If someone ask during grooming, “When will this get done?,” the answer is, “That doesn’t matter.”

Get the Story Right

Make a Statement

Who is the Real User?

Next you will look at the top unblocked and ungroomed story. Review the story statement, meaning the “As…” line. Each of the three parts bear scrutiny.

The user, as mentioned earlier, should be the end user of your product or as close to them down the line as you can get. By that I mean, your team might design the device the buyer wants, but first it has to be priced, advertised, ordered, manufactured, pass Quality Assurance (QA), be packaged, get shipped, and arrive unharmed through a delivery system to the buyer. The account manager who sold the device has an interest, not to mention the sales and fulfillment managers and the owner of the company. In theory, any stakeholder or even a member of the team could be the “user” in a story.

However, by making the end user the “gold standard” of users, you maximize the value for all stakeholders. If a consumer is happy with her device, it probably passed QA. Manufacturing, Packaging, and Shipping were able to manage it efficiently, and thus get it to her quickly at a profitable price she can afford. She is not going to take up the time of your Technical Support Department. The upper managers will be happy about the better customer satisfaction ratings, and even happier if she tells all her friends they should buy the device you built well, so sales go up. At each step, you can either help the company reduce its costs or increase revenues—in short, improve profits—by taking actions that will make the buyer happier.

If you work in a nonprofit organization, serving more clients better and faster will have similar effects across your enterprise. Even if the end user is someone inside the company, like analysts using a database you maintain, focusing on them will also please the people between you and them or helped by their analyses.

To help the team try to identify an impact on the end user when someone else has been listed in the story draft, ask, “What will this do for the end user or customer?” If a specific benefit can be found, rewrite the story to reflect that. Take this story:

“As a developer, I want to refactor the xtram.pl method so it is easier to maintain.”

It could be rewritten to:

“As an end user, I want the xtram.pl method refactored, so I won’t find as many bugs in the Extract feature.”

Do not feel like you must list the end user for every story. Certainly you do not need to slow down grooming for that reason. Take a minute to give it a try, and if another user within your company makes more sense, go with that!

However, I’ll opine that a machine or system cannot be the user, for one simple reason. Bear in mind that the Customer role is a substitute for an actual external customer in the ideal Agile situation. A machine cannot be a customer!

What’s the Real Story?

Review the “what” part of the story statement with a very critical eye. This is the time for the question, “What is this story about?” If you get into a big discussion about the requirements of the story during the Planning Ceremony, you did not do a good enough job of grooming. Let that discussion happen during your sprint, and the team may waste a lot of time debating, or worse, by doing work that does not contribute to completing the story. And the task estimates will almost certainly be off.

So don’t rush the discussion of the story statement. If you hear any hesitation or sense doubts, encourage more questions of the Customer or PO. When there’s an initial disagreement, it’s helpful to go to other parts of the story or to the tasks. Those discussions often clarify what the story statement should say. Get consensus on the wording before you declare the story ready for a sprint, though.

As questions are raised and answers given, ask the Scrum Master to jot them on the story card. Often I will put a “Notes” section below the Acceptance Criteria and capture understandings the team agrees on. These should be brief, usually just bullet lists, with only enough information to remind the team what the answer or agreement was. Remember that Agile minimizes documentation. But recording answers saves time that is otherwise lost when people forget what was decided later and re-ask the question—or do incorrect work.

Beware, though, of what I call “solutioning” in those discussions. Sometimes referred to as “going down a rat-hole” or “getting into the weeds,” this relates to deep discussions about how the story will be accomplished. Again, the point to grooming is to thoroughly understand what must be done. The “how” will mostly be up to whoever volunteers for the tasks.

That said, sometimes some solutioning is necessary to identify risks and dependencies (discussed below) and estimate those tasks. For instance, the team might have to choose between a simple approach you understand well, which will be quicker, or a more complicated route the team does not understand well but is more efficient in the long run. Clearly the first will be a smaller story with fewer risks, but the team may realize better value from the second. It is helpful, though not necessary, for the team to decide on a general direction so the estimates and risks are more correct. However, you can also simply estimate according to the more complicated solution, as that will obviously provide you with conservative estimates. Don’t be afraid to say, “Let’s assume the worst,” and move on.

If anyone thinks the team is getting too “weedy,” ask whether that level of solutioning is needed to estimate the tasks. Only continue the discussion for as long as the team’s answer is “yes.” You will save meeting time if you’re not afraid to ask the question again and again.

Why Do the Story?

Knowing the purpose of the story can change the design of its solution. A requested change in the user interface (UI) of a Web site might be needed to reduce customer complaints about the required fields in forms. Or, it might be required to comply with a government regulation. (For example, U.S. companies are required to identify the country of the buyer for certain kinds of products.) In the first case, the complaints would be the best guide to the design and function of the UI change. In the second case, the story assignees will need to ensure the solution meets the regulation even if the change increases customer complaints! The purpose can affect the Acceptance Criteria and the team’s understanding of the risks, external dependencies, tasks, and task estimates.

If any of the three parts of the story statement does not make sense to any team member as written, rewrite as a group until it does. No one should be forced to commit to completion of a story if they do not fully understand it. Remember that the entire team commits to completing every story in the Sprint Plan, regardless of who works on it.

⇒ Steps: Groom a Story

The Power of Acceptance

We all like to feel accepted, even user stories! The Acceptance Criteria are arguably the most important part of any story. Because that line becomes the goal of the story, the team must maintain a laser focus on getting it completed exactly as written. To satisfy the customer, it must be done; to save time and meet the Agile Manifesto principle of “Simplicity,” only it should be done. The criteria prevent any effort on deliverables customers might not want, no matter how cool the additions seem to team members. Pour any additions, sometimes called “gold-plating,” into a new story and run that by the Customer for possible inclusion in a later sprint. Encourage innovation, but validate its value before spending money to develop it.

The Acceptance Criteria take the form of a “SMART” goal:

  • Specific—With wording so clear, related tasks can be created without further discussion of the goal.
  • Measurable—Including numbers an outsider could use to declare the item “done,” if at all possible, or at least a clear yes/no objective.
  • Action-based—Starting with action verbs like “add,” “increase,” or “reduce.”
  • Realistic—Possible given the team’s skill set, tools, available materials, and other resources.
  • Time-bound—Small enough to deliver within one sprint.

As much as possible, keep this a single sentence that is relatively easy for stakeholders not in the meeting to understand with a glance. Think of it as a summary or bottom-line description of the deliverable, the final proof you completed the story. Additional details can be added further down on the card in the “Notes” section mentioned above. (Other coaches will tell you to put them all in this section, hence the use of the plural “criteria.” There are usually more than one element even in my single sentence, so I stick with that better-known term instead of the potentially more accurate “criterion.”)

Measurements can be tricky. The Acceptance Criteria must strike a balance between adding enough value to justify the work, and the odds of acceptance within one sprint. When the criteria say a system will perform 10% faster, the story cannot be accepted if you only improve by 9%. Set the goal only to 1%, and stakeholders might rightly question whether the improvement provides enough benefit to spend labor time on that story. Of course, if the Customer insists that 1% is valuable, go for it!

Higher numbers are good as long as they fit the “Realistic” and “Timely” needs, but the team should push back when someone says they can get a 10% figure to 20% by putting in some extra hours. This will take hours from other incomplete stories and add risk that those stories will not get accepted. Complete the other stories first, and then improve further within the sprint if you have time left. Always think iteratively, though. The better option is to create a new story for the next sprint to improve the function by that extra amount. Improve by 10% this sprint, and then another 10% later. Remember that predictable output is more important than maximum output.

If, as preferred, the requester will officially accept the story, include a “second set of eyes” within the team to verify the results before showing them to the requester. That is, include a task for peer review by another member. When the PO is accepting, he or she serves that role. Either way, the goal is to make sure defects don’t escape the team. Professional editors will tell you they have to have someone else edit their own writing. That’s because it is very difficult to catch problems you personally have introduced into a product, because the same weaknesses or habits that created the problem are still in play when you are checking it. Peer testing, or testers on the team, help to ensure you deliver a problem-free product. Spread those tasks among several people, and you will also increase the team’s shared understanding of the product.

Defining “Done”

At one pre-Agile job I had, a manager got tired of being told something was “done,” only to learn that work he assumed was included was not. For various reasons, the deliverable was not actually ready to release to customers. There might be some minor functionality missing that the customer was expecting. Documentation might be incomplete. Worse, the team might not have tested it as thoroughly as desired due to a looming deadline. He began to ask wryly, “Is it ‘done’—or ‘done-done?’” His teams learned not to say it was “done-done” unless the deliverable was ready for handoff.

A team I trained on Scrum had a conflict with a stakeholder when he heard that a piece of software and its documentation had been completed in a sprint. He thought that meant the documentation was available to his customers. But the team did not have control over the publication process. All it could do was release the files to another team responsible for posting them to the company Web site. This process introduced a delay of a week or so to the overall release. The stakeholder was embarrassed because he had told his customers the new version was available, only to learn it was not.

If you are careful to cover these details in your Acceptance Criteria, they will begin to get repetitive. For example, each end-user story might end with the words, “…has passed function and regression testing without bugs, and documentation is posted to the Web site.” To cut down on that problem, many teams create a “Definition of Done” as part of their Agile process documentation. This specifies what assumptions can be made about a deliverable when a stakeholder hears a story has been accepted.

Think through the actions you take on every story, or every story of a particular type. The ones that are common you can add into a Definition of Done in a document or intranet page available to stakeholders. Examples include:

  • Output peer-reviewed.
  • Deliverables meet applicable company specifications.
  • Functional and regression testing passed to company standards.
  • Documentation updated and posted.
  • Updates given to Customer Support.

Having defined “done-done,” you can focus your Acceptance Criteria on measures specific to the story.

⇒ Steps: Create Acceptance Criteria

Caring for Dependents

Types of Dependencies

What a glorious life it might be if we never had to depend on someone else to accomplish things! That is not the world we hyper-connected humans live in (nor would I really want to). Even in the ideal situation of one small team working on a product for one customer, that team has dependencies on the customer for information, and probably other departments like Maintenance or IT for infrastructure.

In the modern workplace, it is more often true that other teams or individuals must help you accomplish your team’s project work. Maybe they have a skill set your team does not normally need. Maybe you need access to specialized equipment another team is responsible for. Perhaps the Customer wants a subject-matter expert elsewhere in the company to approve changes you have made. More typically, in larger companies where multiple teams work on the same product, one team may need to finish its work before the other team can start, or the teams are working on different parts that have to be aligned properly to work. Often, too, a story in your backlog cannot be completed until a previous one is accepted.

In any of these scenarios, a “dependency” exists that threatens your ability to complete a story within a sprint. An “external dependency” is any action that must be completed by someone outside of the team before a user story can get done. The last scenario above is an example of an “internal dependency,” meaning internal to the team.

Standard project management practices identify four types of internal or external dependencies to consider:

  • Finish-to-Start (FS)—One action must be finished before you can start on the next one.
  • Finish-to-Finish (FF)—The actions can start at different times, but one must be finished before the other can be.
  • Start-to-Start (SS)—You cannot start one action until the other is started, but you do not have to finish either before the other.
  • Start-to-Finish (SF)—One action must be started before the other can finish.

In FuSS™, the “action” can be an epic, story, or task, or some type of effort from a non-Agile team or individual. List any dependencies somewhere below the Acceptance Criteria on the story card, and ask whether:

  • Action items or tasks should be created to address those dependencies.
  • The story should be blocked, meaning you should not put that story into a sprint until the dependency is cleared.

When possible, create a user story for the preceding action, whether for your team or another. A digital tracker may have a feature for showing the link between the stories. In a paper tracker, note the connection on the story card.

The FS and FF types are by far the most common, in waterfall or Agile. An FS is almost always a “blocking dependency” until the previous action is done. The same is true for an FF, though you are likely in that case to have to start your action based only on a commitment from the other group/person to get theirs done in time.

In Agile, the SS and SF types most often apply to tasks within a story, giving your team greater control over them. Coordination of internal dependencies of any type are primarily done via the tracker and scrums.

Coordinating with Outsiders

External dependencies are always an issue in projects, especially those large enough to require more than one team, or when working with vendors outside the organization. This is true whether both sides are doing waterfall, both are Agile, or one is an Agile team and one isn’t. In each case you will more likely deliver the coordinated work smoothly if you communicate early and often:

  • Notify the other team of the dependency as soon as you identify it.
  • Block your story—do not put it into a sprint—until, for a:
    • Finish-to-Start—They complete the deliverable.
    • Finish-to-Finish—They commit in writing to provide their deliverable by the specific date you need within the sprint.
  • Notify them when you start.
  • Follow up regarding progress regularly.

For blocking dependencies, create an action item to follow up with the other team or individual. Only groom the story enough to tell the other people exactly what you need. I urge you not to plan the story into a sprint until the blocker is cleared. Time and again, I have seen teams filled with optimism go for it, only to be disappointed. Sometimes the delivery is only a day late, yet that is enough to prevent completion of the story within the sprint. At least have the other folks’ commitment to the delivery date in writing (an e-mail is fine) before the Planning Ceremony.

You may also want some tasks in the story that directly address the dependency. Typically these are very small “reminder” tasks included to ensure a critical communication occurs, such as:

  • “Remind (team/person) of the deadline.”
  • “Coordinate with (team/person).”

The first one usually goes at the top of the list; the volunteer for it will be wise to call the other team/person immediately after the Planning Ceremony The second appears wherever it is appropriate based on the sequence of work.

I take those steps regardless of the other team’s project management method (or lack thereof). For another Scrum team, coordination should be easier. Then the Product Owner can propose or place a story in the other team’s backlog. This situation is ideal for the simple reason that both teams have the same incentive to get the stories accomplished, and both understand the importance of the deadlines. They both want their stories accepted!

When the teams are using a digital tracker, I recommend POs be granted editing rights in each others’ backlogs to make this easier. Some trackers allow you to link dependent stories across team lines. However, do not rely on the tracker to communicate the need. Per the Manifesto, you must follow up with “face-to-face communication” or as close to that as you can get (a phone call instead of an e-mail, if not collocated).

Shared Stories

For an dependency that must be done by two Agile teams at the same time, create what I call a “shared story.” This is a copy of the same story placed in each team’s backlog, and then modified to reflect each team’s specific role. The PO for the requesting team sends a copy to the cooperating team’s PO and suggests or requests a sprint in which it can be worked.

The cooperating PO is responsible for:

  • Rank-ordering the shared story such that it gets into his or her team’s appropriate sprint to meet the requesting team’s needs.
    Note: This may be in the same sprint if the two teams are on the same cycle, or an overlapping one if not.
  • Creating or revising the draft task list so it only shows tasks the cooperating team will do (something the requesting PO would also do with her version of the shared story).

Bear in mind that these stories can be done serially or in parallel, depending on the nature of the story. That is, it may be that Team 1 has to complete its version before Team 2 can complete its version. In that case, Team 2’s version may get re-blocked during the sprint if Team 1’s gets delayed. Note that both teams could have the two communication tasks listed above.

This decision flow chart illustrates the process for managing any type of dependency:

⇒ Steps: Address Dependencies

Projects are a Risky Business

From Unknown to Known

Obviously things will go wrong in your project, no matter how well you think through your stories. Some of these can be predicted with a little extra thought, though. Risk management in Agile is not about predicting everything that could go wrong in the project (creating a waterfall “risk register”). Instead, the goal is to predict the big stuff that could go wrong in a given story or epic and decide if steps are needed to reduce the risk.

Former U.S. Defense Secretary Donald Rumsfeld famously identified three kinds of risks:

  • Known knowns”—Risks you know well enough to decide whether preventive measures are needed, and what those should be.
  • Known unknowns”—Areas of risk you know are out there, but whose specific risks can’t be predicted well enough to assess.
  • Unknown unknowns”—Risk areas you can’t predict.

One goal of risk management is to move items up the chain:

That is, you want to turn some “unknown unknowns” into “known unknowns,” and convert as many “known unknowns” as you can to “knowns.” For both “unknown” categories, the team may want to do a spike story first that better identifies the risks and possible ways to address them. Or it can create action items or story tasks to do so.

Larger project risks are identified via the requirements gathering process already described, resulting in business and technical requirements. Projects using epics add an additional level by assessing epic risks using this same story process.

For each “known known,” the team should assess the risk and decide what to do about it. Most of the time, these turn out to be dependencies, so I handle them per the previous section. Any others I list in a separate “Risks” section on the story card. The team then can consider what action items or tasks are needed to address the risk, if possible. For action items, ask if you should block the story until those are completed.

Every team I’ve worked with has claimed no risks in virtually every story at first. I’ve learned to let them make the mistake. Because in every case, some stories failed in their first sprints due to reasons they could have predicted had they thought them through. The SM should point these out during the Retro, though often the team realizes it without my help. Resistance to the risk exercise drops rapidly after that. In my experience, eventually mature teams will still have no risks in most stories, but include in the average sprint several stories with dependencies or other risks identified.

Some risks are inherent in almost every story your team will do. It is always possible that someone will get sick, or a unique machine will break, or a crisis will arise that pulls the team off sprint work. It isn’t realistic or necessary to list all these risks, especially since a reasonable Customer will understand why your promise could not be met. Focus on risks particular to your project.

Calculate the Risks

For more complex or troubling risks, you can borrow a technique from standard project management. Have the team rate and assign “impact” and “likelihood” numbers for each risk. Then decide on one of four traditional responses.

When rating risks in Agile, we are not talking about an extended effort to find hard numbers. Simply ask, “How big of an impact could this risk have?” The kind of impact depends on the kind of risk. The question for a risk to a story is, “How big of an impact on the story could this risk have?” Usually this means harm due to a bug or dependency the team doesn’t catch. But there also can be a risk from a story. The question could be, “How badly could this deliverable harm the customer’s operations…” or “the company’s profits?” There could be unintended consequences from doing a story right that cause it to do harm as well, maybe more harm than good.

Have the team use this simple scale to rate the possible impact using its collective wisdom:

  • High—3.
  • Medium—2.
  • Low—1.
  • None—0.

Then, using the same scale, ask and rate: “How likely is this risk? “What is the chance it will happen to us?” So you will end up with two numbers for each risk. A zero rating for either means there is no risk, so you may ignore those. For all others, total the numbers. Any that have a total risk of at least a 4 warrant further discussion, I believe. Note that all of these combinations total a 4, and thus could trigger a discussion about whether and how to address a risk:

  • Impact = 1, Likelihood = 3
  • Impact = 2, Likelihood = 2
  • Impact = 3, Likelihood = 1

Your team may be more or less risk-averse, and choose to review a 3 or only a 5 or 6. This could depend on your industry and the story type, too. On a critical story in a highly regulated industry like medical devices, anything above a zero might warrant review. It might even be required under contract or by regulation, in which case it will behoove you to create fields in your digital tracker to prove compliance.

For those risks you review, determine which of these methods should be used to handle the problem[2]:

  • Avoid—Change the story or your solution to get rid of the risk.
  • Transfer—Shift the risk to someone else—for example, by outsourcing part of the work, getting another team to do the story, or buying liability insurance.
  • Mitigate—Take steps now to reduce the impact or likelihood of the risk, such as building extra tasks or labor hours into the story to cover the possibility.
  • Accept—Take no action unless the risk arises.

If you get a score of 5 or 6, I strongly urge you not to “Accept” the risk! That risk is a significant threat to your sprint or customer satisfaction. In less risky scenarios, accepting means all you have to do is record the decision on the story card in case questions arise later. For the other options, again, either create action items to be done before the story is worked, or tasks to implement the option as part of the sprint.

Bear in mind the net costs (not only money costs) of addressing the risk versus the possible loss or benefit. Spending hours on a risk means taking away hours from other work you could be doing. That’s not a valid excuse for not mitigating, but the degree of mitigation should be reasonable. Try to live a no-risk life, and you’ll never leave the house—or take a shower, given the number of deaths from bathtub accidents.

⇒ Steps: Address Risks

Take Them to Task

Start the Grocery List

Although many Scrum coaches would tell you to wait until the Planning Ceremony to add tasks, or let people working the story add them on their own, doing so as a team during grooming has several advantages. The process of “tasking out” the story often spurs new technical questions and helps the team think of more risks and dependencies. Researchers into teamwork agree that robust discussions by a team increase innovation and accuracy, in this case by bringing multiple perspectives to bear on the tasks.

What I call the “Grocery List Approach” also introduces the benefit of time. Go to the market without a list, and you are far more likely to come home without stuff you needed, and with extras you didn’t. Take one you made right before leaving, and the latter usually doesn’t happen, but you’ll probably realize during the week you left something off. Smart shoppers keep running lists, or at least start one a day or two before the next trip. Like the rest of the user story at this stage, a task list created during grooming becomes a “draft” that often is improved after people have time to think it over.

As much as possible, put the tasks roughly in the order the team is likely to do them. This will make it more obvious when someone needs to get their task done to enable someone else to start on a later task—that is, when there is an internal dependency between tasks. In some stories, there will be an obvious order: design the solution, do the work, test it, etc. In others, there may be a task that can be done anytime within a set of tasks, in which case you can just put it before a task that definitely must come after it (an SS or FF dependency), or at the end. The order does not imply the work must be done in that order. It is mostly another means of communication, though it can also be used to reinforce best practices: It makes no sense for a test task to be marked as “Complete” during a sprint if the development task isn’t done yet, though I have seen that mistake made! A more subtle example is if you always want someone to do a code review before formal testing, always put that task higher in the list.

To save time when grooming similar stories, create template stories you can copy to create the new ones or from which you can copy the task lists.

Keep it Short and Simple

Try to limit your tasks to a single working day or less, and an absolute maximum of two working days in development stories. As mentioned earlier, spike story and placeholder tasks are two logical exceptions.[3] In all other cases, longer time frames introduce more uncertainty and are harder to estimate accurately. They also suggest you are not really thinking through all the steps required. When I push people on this, they are always able to break the work down. My method is simply to ask:

  1. “What will you do first to accomplish [task name]?”
  2. “Then what will you do?”

The same principles suggested earlier for breaking down stories apply here as well (under “Epics”).

My tasks are almost always one short phrase. There is no need to repeat information from the story. When the story is titled, “Shift wire route for thermostat sensor,” the design task can just say, “Choose route,” not, “Choose route for thermostat sensor.” And in most cases, details you are tempted to add to the task are better off going into the story notes, to answer questions stakeholders and others may have. Those folks won’t know to look in the task. I have even seen teams puzzle over where some information is, only to remember it was recorded in the task instead of the story card. Better to just put it in the story card in the first place.

Example task lists are in the “Template Stories” section I just referenced and elsewhere on the site. I mentioned early on that I used an Agile approach to stain the back deck of my house. I didn’t bother writing this down for my “team of one,” but mentally I treated each section as a user story with this task list:

  1. Move tools and materials from garage.
  2. Clear debris, plane rough spots, hammer in raised nails.
  3. Sweep railings or vacuum flooring.
  4. Spray with cleaner, wait 5 minutes, hose down.
  5. When dry, stain.
  6. Return tools and materials to garage.

Obviously these were very small tasks for a story I could do in a single day, but following this routine helped me stain each section efficiently.

Don’t assign names or hours to the tasks until the Planning Ceremony. This can save time overall because the tasks, or people’s availability, may change prior to then. Rather than spend time assigning and reassigning them, estimating and re-estimating, just wait until Planning for that part.

Remember that the task list is not final or “written in stone.” First, you will have an opportunity to add, remove, or revise tasks during the Planning Ceremony. Also, even though you will not add stories after a sprint has started,[4] team members are welcome to revise or add tasks. After all, it’s not uncommon to start some work and realize you need another task, or don’t need one you thought you did.

A digital tracker will likely have a function for adding a task list to a story. Teams using paper cards will attach sticky notes on the back or vertically to each other, like this:

⇒ Steps: Create Tasks

Consider Acceptance Test-Driven Development

The Benefit of ATDD

An Agile method known as “Acceptance Test-Driven Development” (ATDD), has been shown to greatly reduce the number of bugs a team creates. The reason is wondrously simple: You know what test you must pass before you start, so you are less likely to introduce mistakes that will cause a failure. Plus, each team member can run the test before passing the work to the next person in line.

Originally ATDD was conceived as involving the customer and team in creating test cases together in business language. That is a lovely idea, and if you can get your Customer to participate, wonderful. I’ve never had one willing to dedicate the grooming time involved. A more realistic approach is simply to make the first task in most stories, “Create test case.” A test case lists the steps the tester will use to ensure the product now does what the Acceptance Criteria said it would. In some cases you may already have a similar test case, so you simply need to “Revise test case.” Regardless, research and development of the solution do not begin until the test case is ready.

You can apply this to almost any project, not just software. If you are delivering a plastic ball, there are manufacturing standards that ball must meet. Anything you do in the process of creating the ball must contribute to meeting those standards, and you can write a test to ensure it does. Skip the next section if you already know how.

Writing Test Cases

A test case walks someone through the steps to use the function or product you are testing. As with standard operating procedures, the best-written ones assume someone new to the product is running the test. What would someone who had just joined the company out of high school need to know about bouncing a plastic ball to test its bounce standard. Should they bounce it on the floor? On the wall? Off their heads? Should they bounce it with all their might, or by simply dropping it from… two feet? Four feet? What will the ball do after they drop it, if it meets the standards you are looking for?

I know, I know, all of this is automated and machine-tested these days. Please play along with this example to understand the concept!

A test case like the following won’t provide you with consistent results from person to person, because there are too many different ways to interpret it:

  1. Bounce the ball.
  2. Make sure it bounced enough.

This is more like it:

  1. Go to the measuring chart on the back wall of the warehouse by the fire door.
  2. Face the wall, and hold one hand:
    1. Palm up.
    2. Fingers together and straight.
    3. With the tip of your middle finger touching the four-foot mark.
  3. Use your other hand to place the ball on the upturned palm.
  4. Turn your upturned hand over as quickly as possible to drop the ball.
    Note: Ensure the ball drops into the circle on the floor at the bottom of the chart, and repeat steps 2 through 4 if not.
  5. Observe the ball to ensure all of it rises above the three-foot line on the wall, regardless of the angle of bounce.
  6. Repeat the test twice.

Expected result: The ball clears the three-foot mark all three times.

This if a goofy example, of course, but you get the point. Do not make assumptions about what the user of the test case knows. Cover every step. Even if you are the primary user, someone else may eventually use it or need to understand it. More importantly, the more freedom you allow the developer by leaving assumptions in the case, the more likely it is they will do something that does not meet the requester’s expectations.

Attaining the Expected Result

One of the last tasks on any story using ATDD will be, “Run acceptance test.” When the story is complete, someone shows the test and results to the requester. Unless that person feels the test didn’t accurately reflect the criteria, the team is guaranteed acceptance of the story if the test passes, eliminating any confusion about what people are supposed to be doing and whether they did it.

However, what if the test fails? The standard approach is for the tester to create a defect with the “actual result” as opposed to the “expected” one. The reason you have a “Fix bugs” task is to set aside time for someone to make further changes as needed until the actual result matches the expected result. This is another technique in FuSS that simultaneously prevents overcommitment while increasing the odds of story acceptance within the sprint. Other techniques ensure time not needed for a story is productively used.

Consider ATDD

Like other “one time” steps, I have not created a set in the “Steps” section for considering Acceptance-Test Driven Development. Before your first Grooming Session, have the Scrum Master:

  1. Send a copy of these ATDD sections to all team members and ask them to review it prior to the session.
  2. During the meeting, facilitate a discussion on whether to try it, either immediately or later.
  3. If:
    • Now—Add at least these two tasks to each relevant story:
      • “Create test case”—Before any development tasks, though research tasks can come before.
      • “Run acceptance test”—After development and all other testing tasks (such as “unit testing”).
    • Yes, but later—Create an action item to re-consider it by a date selected by the team, and repeat these steps at that time.

Groom to the Goal

Stressful and irritating things can happen if you do not get enough stories groomed at the top of the backlog prior to each Planning Ceremony. First, that meeting will often run overtime, occasionally badly so, because you use up time for more grooming intended for Sprint Planning. Sometimes you will leave people without enough work to do in the Sprint Plan. In that case, or if people finish sprint work early, they risk working on stories in the backlog that are incomplete, wrong, or low-priority. These problems primarily arise from:

  • Not setting a high-enough goal for the number of stories.
  • Not allowing enough time for grooming, or allowing bad habits like solutioning and backtracking.
  • Not having the backlog correctly rank-ordered going into Planning.
  • Introducing new high-priority stories after the last Grooming Session.

Those last three points are addressed elsewhere. The number of stories you need to groom will vary depending on where you are in your transition to Scrum:

  • Before your first sprint, your goal is merely to groom more work than you normally would need for the period covered by the sprint using your pre-Agile practices (see the guidance under “Set Initial Grooming Sessions.”)
  • After the first Planning Ceremony, aim for 50% more stories than you got accepted in the previous sprint.
  • As you begin to establish a stable velocity (number of stories accepted each sprint), keep 150% of your velocity groomed and unblocked at the top of the backlog.

Adjust that figure as needed in the first couple of sprints. The reason you need more than your velocity will become clearer in the sections on the Planning Ceremony, but for various reasons high-ranked stories end up getting skipped in that meeting. If you have only groomed to your velocity, and you have to skip stories, you now have to groom those stories during the ceremony. (This skipping can happen during Grooming Sessions as well, which is why the goal for the Pre-Grooming meeting is 200% of velocity, to ensure the team can still groom 150% of velocity).

On the other hand, you are trying to get “just enough” stories groomed, up to that 200% figure. The deeper you go into your backlog, the greater the likelihood you will waste time grooming stories that get removed or reprioritized lower before the next sprint.

To illustrate, if you get at least nine stories accepted in the first sprints or are consistently delivering that many, at the start of your next Planning Ceremony these two criteria should be met:

  • Have 14−18 unblocked and groomed stories near the top of the Backlog (150% of 9, rounded up, through 200%).
  • No more than two ungroomed stories should be within that range—for example, if that 18th story is in position 21 in the rank order, that should be because three above it are blocked, not because they are new and ungroomed.

I suggest you find a way to mark each story when you consider it groomed. One digital tool has a “Ready” checkbox convenient for this: Mark the story “Ready” when groomed, then include that field in your backlog list, and it’s easy to tell if you have hit your goal. A colored marker or sticky dot can serve that purpose for a paper tracker. Once a story is marked as groomed, there is no reason to go back over it in later grooming sessions unless someone has a specific reason to do so, per the “No backtracking” meeting rule. Don’t waste time!

Summarizing the process, let’s take the story card from another part of the site and show what it could look like after grooming:

⇒ Steps: Groom to the Goal

The Sprint Process | ← Get the Team(s) Started | → Plan the Sprint


[1] A temporary team with representatives from different organizations formed to find ways to improve quality or operations.

[2] List based on that in the PMBOK (Project Management Institute 2013).

[3] See “Other Story Types.”

[4] See “Toe the Goal Line.”