Contents

• Create User Stories
  • Prepare a Backlog
  • Gather Requirements
  • Follow the Format
  • Other Story Types
• Create a Team Charter and Meeting Rules
• Schedule Meetings
  • Set Initial Grooming Sessions
  • Choose Ceremony Days and Times
  • Refine the Grooming Schedule
  • Sample Schedules
• Create a Quality Mindset
  • Reasons, not Excuses
  • Prepare to Track Defects
  • Set Criticality Levels and Responses
  • Triage and Resolve Defects
• Create Action Items

---

Create User Stories

Prepare a Backlog

The Customer and Team Guide can begin gathering requirements in the form of user stories as soon as the team decides to try Scrum, but cannot finish the drafts until the sprint cycle is determined. Some stories may take only a day or two, but none are allowed to take more than the sprint length. You can, however, combine stories into larger requirements, as explained under “Epics” below.

You will find it easier to keep everyone busy if most stories would take half the sprint length or less. The reason is task hand-offs. For example, in software a tester could create a test case and hand it off to the developer. While the developer was busy coding to that test, the tester could be writing the tests for the next couple of stories. Around the time he finished those, the developer would be done with the first code and could hand it off for testing. Then she starts on the next test case as the tester starts testing.

While researching digital trackers, teams can start writing stories in a spreadsheet program. Any software tool you try later should give you the means to upload them, and the templates I have seen on the Web for paper trackers use spreadsheets also. A digital tracker will have a function for adding new stories.

For those using releases—which I don’t recommend for teams new to Scrum—work in the Product Backlog first. Then move stories into the first release backlog after you have seen them in the context of the entire set. From this point on, I’ll use the generic word “backlog” when referring to either the Product Backlog, Release Backlog, or Epic Backlog, whichever you use for Sprint Planning.

Gather Requirements

Requirement Types

There are four types of requirements in FuSca™, drawn from standard practices in product and program management:

• Customer/User—Functions and features requested by a customer or the end users of the product or service.
• Market—Features not requested by a customer, but considered necessary for the product or service to compete in its market in the future.
• Business—A deliverable, usually information, from your team needed by another unit in your company to sell, produce, support, etc., your product or service.
• Technical—Work invisible to stakeholders (except in the tracker) but needed by the team to deliver the other types of requirements.

They all are written in the same user story format and are handled the same way throughout the development cycle. (This is true for both user stories and epics.) They do not need to be identified by requirement type in the tracker. The only reason I call them out while coaching is to ensure they get identified and done. When converting organizations to Scrum, I almost always get questions like these:

1. How do we make room for innovation?
2. What about other needs, like documentation?
3. How do we handle legacy defects or setting up infrastructure?

The answers are that market (#1), business (#2), and technical (#3) requirements get created, prioritized, planned and developed just like customer requirements. They are not treated as “extra” work—they are part of the work. This table shows who usually creates each type:

Type/Role	Customer	Arch[1]	AL	ARM	TG/Team
User	√		√
Market	√		√
Business	√	√	√	√
Technical		√			√

The next four subsections explain each type and the column headings in detail.

Customer or User Requirements

Sit down with the customer(s) and develop an initial list of key features and functions they want from the project. This is done by our capital-“c” Customer role in most organizations, though in small ones it may be the Team Guide working directly with external customers. Usually those need some massaging into the format mentioned earlier and detailed under “Follow the Format” below.

Other sources for user requirements include:

• Requests for proposals (RFPs), contracts, and statements of work (SOWs).
• External customer points of contact.
• Executives who interact directly with customers.
• Sales and marketing staff members, especially account managers.
• Customer support databases (for reported defects deemed instead to be new feature requests).
• Online user groups related to your and your competitors’ products.
• Social media.
• Web site feedback forms.
• Development team members, especially for ideas users may not have thought of, but would like.

No prioritization is needed other than rank ordering (1, 2, 3, etc.). Sources like RFPs that use a scheme such as High-Medium-Low can give you the first cut at that order, but should not be transferred into the tracker. They add no value once rank order is established, and thus are a waste of time to track.

Market Requirements

Part of the job of a product manager is to research market trends and use those to predict what customers will expect your product to do in much later versions, say three to 10 years out. Even better are qualities the customer will not expect, but would be delighted to have. If you don’t have a product manager, your marketing department may have that responsibility, and if not, your sales people may have some ideas.

Do not let market requirements get lost in the drive to get something out the door. The history of business is filled with companies that failed to keep up (Kodak) or succeeded by maintaining a long-term view (Google). Apple nearly became the former, but survived and thrived by becoming the latter. Setting some portion of each iteration aside for market requirements is an easy way to keep your enterprise’s future bright.

Business Requirements

One of the most consistent complaints I’ve heard in a variety of industries over 30 years boils down to, “They always forget about us.” The “us” is nontechnical teams that must do something related to a project to support the customers or the needs of the business. Just when a release manager thinks they have covered all the bases, it seems, another team raises a hand—or worse, an objection.

Failing to account for all of these needs can be devastating. I’ve lost count of how many projects I witnessed or heard about that the technical people considered ready to release, only to find out one of those must-have tasks have not even been started. At the very least, it adds stress that could have been avoided. In waterfall, it often results in people putting in overtime, costing them family time and (if hourly) the company money as they try to squeeze in unplanned work before a deadline. At worst it results in a product release getting blocked, and a bad surprise for the expectant customer. More often than not, the blocking teams explain, “No one told us about this.”

The answer is business requirements. This is by no means a complete list of possible examples pulled from memory:

• Accounting system updates
• Certification reviews
• Contract/SOW needs
• Customer support database updates
• Implementation procedures
• Inventory system setup
• Labeling design
• Manufacturing qualification testing
• Manufacturing set-up
• Marketing documentation
• Partner information (for and about)
• Packaging design
• Pricing
• Purchase orders
• Safety reviews
• Sales staff training
• Sales tool updates
• Solution architect training
• Security reviews
• System testing
• Training materials
• User acceptance testing
• User documentation
• Vendor requirements/SOWs
• Web site updates

Just as a good waterfall project manager ensures these needs are identified in the project plan, in multi-team programs using FuSca the Agile Release Manager is responsible for ensuring all are covered in the Product Backlog. However, the ARM need not be the primary creator. As indicated in the table above, other roles are better placed to know specifically what is needed in their areas of expertise. In particular, I created the role of Agile Liaison (AL) in FuSca to ensure everyone affected knows about every project. When Manufacturing has an Agile Liaison participating in the high-level release activities of the product development teams, that relatively small investment of time results in business requirement coverage that prevents larger and more costly time losses later.

Technical Requirements

To develop hardware, you must make a lot of technical decisions to meet the user and market requirements. Circuits must be designed. Where does the plug go on the product end of the wire? Should we use rivets or screws? The latter are more reliable, but take longer to put in and cost more, increasing manufacturing costs. All of these must be decided even though the end user couldn’t care less about them.

That is more obvious for hardware, but there are many such “invisible” requirements in HR, finance, and software as well. Determining the architecture is an ongoing process. Test servers must be configured, sometimes every sprint. New laws or regulations drive many changes for administrative departments. Code written hastily in the past probably resulted in “technical debt” consisting of hard-to-maintain methods and bugs that were never fixed. Sometimes development teams are asked to help customers with problems too complicated for Customer Support reps to handle.

Technical stories and epics are used to ensure all of the above get scheduled and therefore done. Among other reasons, these make status reports more realistic in the same way a waterfall project plan will only be realistic if the time required for that work is included. Teams also use technical requirements to ensure the work is completed before dependent user requirements are tackled. This is done by showing the dependency in the tracker and ranking the predecessor higher in the backlog.

Follow the Format

One of the classic “use case” requirement formats from product management is:

• User
• Function
• Purpose

FuSca, like many methods of Agile, uses a similar format for user stories:

As a [type of user], I want [to do this] so that I can [achieve this purpose].

For the “user,” choose the end user of your product or service if at all possible, or as close to the end user as you can get within your company’s delivery chain. If you are creating a 3D printer, for example, the person pushing the buttons on the printer is the person to focus on. But maybe your sales people need a mockup for pre-sales, or later on, your company’s technical support people need access to a log. For a purely technical story, like doing scheduled maintenance on machines your team uses, your user might be “a machinist” or even “the team.” In practice, though, my teams have all been able to name end users for the majority of their stories. If you cannot show that most of your work relates to end users in or outside of your enterprise, I tell them, I question why your project is needed.

After the three-part statement, add your suggested Acceptance Criteria—the standard the customer or PO will use to determine if the story was completed (detailed in a later section, “The Power of Acceptance”). If you like, you can also add draft dependencies, risks, tasks, and limited technical notes as described under “Get the Story Right.” These are not required at this point, but the more information you add now, the faster your Grooming Sessions should go, because the team will have fewer questions to answer. Do the math: Five minutes you spend doing something during a meeting with a five-person team instead of doing it by yourself beforehand wastes 25 minutes of labor time:

That said, when you first write a user story, it is like any story you ever wrote back in your school days. It is just a first draft. The team will help you “get it right,” so don’t get hung up on perfection. Quantity is more important than quality at first.

Other Story Types

Epics

As described already, an “epic” is a requirement that takes more than one sprint to complete.[2] Another term for an epic is a “parent” story, since an epic spawns a series of related “child” stories. I try to avoid epics. They violate the spirit of delivering a “potentially releasable product” each sprint. In effect, an epic is a return to a waterfall process for that set of work, with some or all of waterfall’s inherent problems. That said, epics are unavoidable for hardware projects and if you have to use releases, as described in “Plan in Releases.”

If you think a story will cross sprint lines, first make every effort to chop it down. If you need to make small changes to 1,000 lines of code, do 200 in the first story start-to-finish. Though this may seem inefficient, it also will point out potential problems sooner and make the later work go faster. Think of the first 200 lines as a pilot test for the proposed change, except it produces a releasable output. Later you may be able to do the remaining lines in two stories of 400 each. However, if you have chopped a story as much as you can and still think it might take more than one sprint, you are better off creating an epic than making up waterfall-like phases of the work just to meet the rule (a “Design” story, “Develop story,” and “Test” story, for instance).

Every digital tracker I’ve worked with made it easy to link an epic with its children. On paper trackers, keep epic cards to the left of the product backlog and use color coded dots on them and their child story cards. Another option is to re-use keywords from the epic’s name in the name of each child, or if you don’t use names, above the story statement. To build a doghouse, you might need an epic called, “Create a doghouse foundation”:

• As a dog, I want a raised concrete foundation for my doghouse, so I stay dry and healthy.
• Acceptance Criteria: A level, solid 3-foot by 5-foot concrete foundation exists with a surface two inches above the ground.

It could have these child stories:

• Foundation: Research the method
  • As a doghouse builder, I want to know the best way to create a solid, raised foundation so I can save time and money.
  • Acceptance Criteria: My spouse agrees with the instruction set I choose from the Web or a book, and the materials list, for creating a 3-foot by 5-foot foundation.
  • Tasks:
    • Look for instructions on the Web and at the home store.
    • Decide which option to use.
    • Write down the supplies I will need.
    • Discuss the results.
    • Revise option and list if needed.
• Foundation: Pour and Test
  • As a dog, I want the foundation for my doghouse flat and solid to meet the epic criteria.
  • Acceptance Criteria: The foundation is flat and solid.
  • Tasks:
    • Purchase the supplies.
    • Build the frame.
    • Mix, pour, and smooth the concrete.
    • Test for level and hardness (after curing).
    • File flat if needed.

Spike Stories

A “spike” story receives no sizing or estimates in most Scrum approaches because it is considered impossible to estimate. Usually these stories represent work that could take you down many paths before you get to the solution, such as:

• General research—Those that will impact the overall direction of the project or a set of stories.
• Root-cause analysis—Used when something has gone wrong and you are trying to find out why.

Because FuSca tries to prevent overcommitments, spike stories are still estimated in order to carve out sufficient time for them. They are written using the same format as any other, but:

• The Acceptance Criteria will probably be a document, preferably reviewed by someone else for clarity or technical feasibility.
• Risks are unlikely, since you won’t be building anything as a part of the story.
• Tasks may violate the usual guidance to limit them to two labor days or less—instead the volunteer states how many hours they would like to spend on the effort, and uses that as the “estimate.”

Given the Agile approach to documentation, the output should not be a fancy report. A one-paragraph e-mail to interested parties may be sufficient, or better, a bullet list written into the story (in a digital tracker). Standard criteria statements I use are, “Solution documented on a wiki page and peer-reviewed for clarity” or “…approved by the team.”

Planning for the Unplannable

In disorganized organizations, teams or critical team members are regularly pulled into unexpected meetings. They may often get sent off to “fight fires.” In any firm, teams improving a product in use may have customer support duties. Since these kinds of tasks take time away from sprint work, but the time hits can vary wildly from sprint to sprint, members wonder how to account for the problem during a Planning Ceremony. I recommend using one of two ways: via capacity, or using “placeholder stories.”

The easy approach is to estimate how much time individuals spend on such nonsprint activities each week, and adjust their individual availability for sprint work (“capacities”) accordingly. Say that support work was part of Kenyon’s job description. He would think back over the past month and decide he spent, for example, at least five labor hours a week on support, and sometimes twice that. His Facilitator could ask him to provide a “high average.” If he said six or seven, she should go with the seven and suggest that Kenyon remove 20 hours from his capacity for their three-week sprint (7 x 3 = 21). In some sprints there will be a heavier support hit, but some preparation is better than none. On sprints with a lighter hit, he might have time to do some preliminary work on upcoming stories. (As detailed later, once someone has done all the sprint tasks they can, they may start work “out of the backlog.”)

The major disadvantage of this method is you never learn how much time you are actually spending on nonsprint work, and thus whether your reduction amounts are accurate. That’s one reason why many Scrum coaches recommend you track all work done by a Scrum team in the tracker. This is a simple way to find out where time is leaking from capacity estimates, and to maximize capacity accuracy such that you can maximize the amount of work you commit to.

To use this approach, create a story for support (or other nonsprint) work every sprint. Then create a placeholder task carrying an estimate of time that person needs to set aside. The end result might look like this:

• Name: Customer support
• Story: As a customer, I want defects fixed and questions answered quickly so I get full value for the money I spent on the product.
• Tasks:
  • Provide support—8 hrs—Member A
  • Provide support—20 hrs—Member B
  • Provide support—5 hrs—Member C

One of these is an exception to my normal recommendation to never go over one labor day in a task. That’s because this is a placeholder for a number of tasks. The team may choose to list individual support requests as separate tasks or defects as they come in, removing estimate time from the placeholder. That is, if Member B got a request he estimated would take four hours, he could:

1. Create a new task named for the request (with no estimate of labor hours).
2. Track the burndown of to-do hours (and actuals if the team tracks those) in the placeholder task (see “Record Your Progress”).
3. Track the status in the new task.
4. At the end of the sprint, set the placeholder to-do hours to zero.

Even without tracking actuals, the member will begin to get a good idea of a reasonable estimate. Keep running out of time to finish sprint tasks? Raise the placeholder estimate in the future. Almost always have to-do hours left? Lower the estimate by the typical amount.

Cross-Training

When a subject-matter expert[3] (SME) always takes one type of tasks, your team is creating a single point of failure. Should that person be out for a sprint—or have a medical problem that keeps them out for a long period—you can make no progress on stories in that area. I took a contract once to fill in for two months for a project manager hit by a car while biking. He could not come back for 10 months. Imagine if he had been the only person on his team with a hard-to-find technical skill!

This has been a point of concern for as long as there have been businesses, I’m sure. The most cost-effective solution is usually “cross training,” in which team members teach each other parts of their jobs or share their skills and knowledge. Getting people to see enough benefit that they invest the time is often the biggest barrier. This is especially true in corporate cultures where expertise is the way to get ahead, so people have an incentive to hoard knowledge.[4] Also, managers may like the idea of cross-training, but find it hard to allow the time required when pressured to meet deadline after deadline.

Once a team realizes it is falling behind on a set of stories because one or two experts keep running out of capacity, convincing people to cross-train gets a lot easier. Cross-training has the added advantage to the team of maintaining momentum when people take vacations or a bigger loss happens, which I call the “Won-the-Lottery Syndrome”: What happens when the SME wins the lottery and is “outta here?”[5] Cross-training also makes work more fun by adding learning and variety, and adds the benefit of new skills on the resume for both the learners and the teachers.

One of the great advantages of Agile in my opinion is how much easier it makes cross-training. The effort is not an “extra”; write stories or tasks for it, and it is part of the sprint. I shouldn’t say this, but I will add another way Agile makes this easier: The team doesn’t have to ask permission to do it. You just add it into your sprint. Too many stakeholders see training as a cost rather than an investment that pays for itself, despite the plethora of evidence the latter is the case. Self-organizing eliminates that blocker.

You can track cross-training as a standalone story, as tasks in a story, or both. Say there was a general skill set or knowledge area you wanted to spread among the team members. You could use this template for a story:

• Name: Cross-train on (skill)
• Story: As a customer, I want more team members to have (skill) so work requiring it gets delivered more quickly.
• Tasks (with the person taking each named in parentheses):
  • Prepare training (the presenter).
  • Review training (another expert).
  • Update materials (the presenter).
  • Present training (the presenter).
  • Participate in training (one copy per attendee, usually the same labor hours as “Present training”).
  • Perform practice exercise (one copy per attendee, estimated individually).
  • Support the exercises (the presenter, to set aside time for answering questions arising from the exercises).

To instead use the task-only approach within a normal story—which works for a smaller skill—you would have a shortened version of those tasks for the expert and for the other member(s) taking on the bulk of the work for the first time, like:

• Prepare training (the expert).
• Meet to train (one copy for each person).
• Support the work (the expert, to set aside time for answering questions).

Obviously the non-experts would allow more time for each task than the expert would have, though in later stories it will be reduced. During a Planning Ceremony, I often see the non-experts ask the expert for help in estimating the work. That person typically says something like, “It would take me four hours, so you might want to allow six since you’re doing it for the first time.”

If the non-expert already had some knowledge of the skill set, you could simply add some support tasks to the normal story like:

• Discuss approach (one copy for each person).
• Support the work (the expert).

Although some time from the expert is still required, it’s only a few hours out of their capacity instead of all the time needed if they were doing the work. This often allows a story to move forward that would otherwise be stuck while also filling out more of the nonexpert’s capacity.

The goal of cross-training is not to eliminate SMEs and force everyone to become generalists—whether they want to or not! Instead it promotes what I call “shoulder expertise.” In this model, each SME has at least two people who share some of the SME’s knowledge and skills, and the SME has partial expertise in at least two other subjects. The overlapping shoulders in this graphic illustrate the concept:

Notice that by shifting our view of the figure, any of the three people could be the expert up front. This provides the team with at least three people who can take some tasks requiring any given skill set. And when an SME wins that big lottery prize, it will take much less time for the shoulder experts to fill the SME’s big shoes than if they were starting from scratch.

Template Stories

To help plan for the unplannable, I suggested putting a placeholder story in each sprint. Obviously the text and tasks for that story will change little, if at all, from sprint to sprint. In fact, most teams find they have a standard set of tasks for their stories, or maybe several sets for different story types. Here, for example, is a pretty typical set for software teams:

1. Create test case.
2. Write the code.
3. Perform unit test.
4. Perform code review.
5. Perform QA.
6. Fix defects.
7. Update documentation.

Another advantage of a digital over a paper tracker is you can set up “template” stories in the Product Backlog with all of the common story information and standard tasks. Then either create each new instance of that story type by making a copy of the template, or some tools let you copy tasks from the template to a new instance. Delete any tasks you don’t need for that instance and add custom ones as needed. In a few clicks you’re ready for grooming.

⇒ Steps: Create Initial User Stories

Create a Team Charter and Meeting Rules

Most organizations recognize the need, and often are legally required, to create the equivalent of a government constitution for top-level teams. By-laws are created together and strictly followed by the boards of directors of global corporations, religious communities, and the local chapter of my university alumni association! They streamline operations by making clear how the board makes and implements decisions, while protecting the organization from legal and ethical problems.

Though not going to the same level of detail, sports teams, schools, nonprofits and many companies create lists of rules or values that members are supposed to follow. Despite understandable skepticism from most people about mission statements, many organizations create these as well. Yet business teams below the board level rarely identify their mission, values, and decision-making processes.

Despite my own skepticism about these missions and values when I first heard about them, scientific evidence changed my mind. It turns out individuals and organizations that set and regular refer to these when making decisions measurably outperform those that don’t. The root of the skepticism, I came to realize, is that most people and groups create and instantly forget them. Many a company wall is adorned with a framed mission statement and values list no one can tell you from memory, and therefore no one mentions during decision-making.

Social scientists say groups that work together for a while always evolve “social norms,” codes of acceptable behavior, without trying. It’s a subconscious, natural process, yet trained observers can identify the norms. When people violate these norms, usually without realizing it, others react negatively and conflicts arise. By having a team talk about these, making them explicit and identifying safe ways to raise concerns, I have seen a measurable reduction in interpersonal issues.

After my conversion by the data to believe in missions and values, I began helping my teams create “Team Charters” as detailed in the “Self-Directed agile” chapter. If your team has not already created one, this is the point in the transformation to start. Though that section is written for people that will not have managers involved in sprint planning, the steps are applicable to any team. The manager will simply identify fewer tasks for transfer to the team when creating the “Administrative Task List” described there. And you can create the charter in parallel with the next steps in learning the sprint process.

The charter can be revised as often as every Retrospective; indeed, many of the decisions made during a Retro are recorded there. During a sprint, however, one of the jobs of the Facilitator is to remind members to stick to the decisions until that next Retro. This is an important factor in building the trust between members that will contribute to smooth function, and in keeping people focused on sprint tasks during the sprint. To quote an old proverb, “don’t change horses midstream.”

You’ll want to read the “Self-Directed agile” section and follow its step sets to create the charter. At the very least, establish and set meeting rules to ensure the ceremonies are run as efficiently as possible.

⇒ Steps (from the “Self-Directed agile” sets): Adopt Meeting Rules

Schedule Meetings

Set Initial Grooming Sessions

When you are starting out, grooming a story will seem to take forever. It is not uncommon for the first few stories to take as much as an hour each. Once you get into the rhythm, you will pick up speed considerably. When I taught a high-school robotics team Scrum, the first story took an hour, but by the third one the kids were already down to a half-hour. Nonetheless, as when learning any new skill, allow yourself plenty of time in the beginning. For the same reason, even if you eventually want to do all grooming and planning during Planning ceremonies, I suggest you schedule some grooming-only meetings to get the hang of it before your first Planning Ceremony.

For all sprint meetings, if you have virtual attendees, create a Web conference and embed the link into your meeting invitation.

⇒ Steps: Set Initial Grooming Sessions

Choose Ceremony Days and Times

Once you know your sprint length and the date by which initial grooming will likely be completed, the team can create a specific sprint schedule. You will need at least these recurring meetings:

Meeting	When	Notes
Planning Ceremony	The first day of every sprint, as early as possible in the day.	Allow one hour per sprint week initially (3 weeks equals 3 hours). You will likely cut that in half once you get rolling, if you have a correctly sized team.[6] However, if you plan to groom and plan in the same meeting, add time as described below at “Grooming Session.”
Daily Standup (Scrum)	Every sprint day you don’t have another ceremony, for 15 minutes (only).	Hold this at a consistent time each day.
Demonstration Ceremony	The last day of every sprint, for 60 minutes initially, as late as possible in the day. The length depends on how many of your stories will be relevant to stakeholders.[7]	Consult with your Customer and stakeholders on times they are usually available.
Retrospective Ceremony	Right after the “Demo” every sprint. Allow 60 minutes initially.	Only team members (including the TG and Facilitator) are allowed. Some teams cut the length in half as they mature. If no one has anything that sprint, adjourn!
Grooming Session	One to two hours each, regularly scheduled or flexible. Start with two two-hour sessions per sprint week, the first about halfway through the sprint; the last a day or two before the next Planning Ceremony; and any others between them.	Cancel remaining sessions each sprint when the grooming goal has been met (see “Groom to the Goal”). Also see the next section.

Share these considerations about sprint ceremonies with the team before finalizing the preferred schedule with them:

• Team meetings are mandatory, in the sense that they take priority over all other meetings except company-wide gatherings (“all-hands” meetings) and emergencies:
  • Everyone must try to schedule their other meetings and personal appointments around the team meetings whenever possible.
  • People should not think when invited to another meeting, “Oh, I can skip the ceremony; it’s not that important.”
  • Given a choice between having a dentist appointment (for example) on the first or last day of a sprint instead of mid-sprint, choose a mid-sprint date, preferably on a day with no grooming session.
• If unable to attend a ceremony, including the Daily Standup, the member should:
  • Notify the team—not just the Facilitator or TG—as soon as the member knows.
  • Make arrangements to supply information the team will need relevant to that meeting.
• Although it seems logical to start and end sprints on Mondays and Fridays respectively, people are more likely to be out for holidays or extended weekends those days. I find it better to use the middle days of the week.
• Aim for times when people do not have standing meetings right before or after your meetings. Not only does this give them a chance to refresh between meetings, it reduces the odds they will run late or have to leave an extended meeting early.
• Schedule the meetings within the team’s core hours—after everybody typical starts work each day, and before the first person regularly leaves. Exceptions can be made if virtual members agree to attend earlier or later than their usual working times. Don’t let collocated members “call in” to the ceremonies on a regular basis; this defeats the purpose of collocation.
• Virtual teams with a large time-zone spread will have to hold meetings before or after normal working hours for some people. Consult with them on their preferences and be sure to allow commuting time if they go to an office. For example, onsite workers anywhere on the globe are likely to be unavailable at predictable times due to commuting, eating, and family time.
• Stakeholders are welcome at any meeting except the Retrospective, as explained under “Scrum Ceremonies.” Combining theory and what I have seen in practice:
  • They usually only come to grooming sessions when invited by the team to talk about specific stories. As a courtesy, when I am facilitating I skip ahead to those stories at the beginning of the session, so the stakeholders can leave afterward if desired.
  • Though invited to Planning Ceremonies as observers (speaking only when asked to), few ever attend.
  • Some will attend scrums regularly, again as observers—often requiring some initial coaching against speaking up!
  • Demonstrations will usually attract some stakeholders, where they can ask questions and make suggestions freely.
  • The team can invite a stakeholder to a Retrospective to discuss specific issues, after which the stakeholder is asked to leave.
• In “An Overview of Scrum,” I mentioned that some teams like to take a day off between sprints. They enjoy having a break from the sprint routine, or having some time to think about other things. It also gives the Facilitator more time to do some administrative work.[8] And it allows the TG and Customer more time to think about how to rank any stories that were not completed in a sprint compared to new stories in the backlog. However, most teams like to maintain their momentum by diving straight from one sprint into the next.

Schedule your first sprint cycle to begin the first appropriate day after you complete your initial grooming sessions. Upon negotiating a preferred schedule with the team, the Facilitator will use the organization’s shared calendar system, if there is one, to set final times given people’s existing appointments. (Or use one of the many free online or intranet tools for this.) In some cases you may need to approach members about changing pre-existing, recurring appointments.

Don’t sweat this decision. There is no “right way” to schedule the ceremonies. You can always change your minds during a later Retrospective if the team wants to try another schedule, especially in the early going.

Refine the Grooming Schedule

After a few sprints, you should be good enough at grooming, and have enough stories groomed in the backlog, that you can cut back on grooming time. As noted in the ceremonies table above, instead of having a regular schedule, you can choose to schedule those on an as-needed basis when there are holes in people’s schedules. The disadvantage of not having regularly scheduled meetings is that the Facilitator will need to stay on top of scheduling lest the team run out of grooming time during the sprint. It is much easier to set recurring meetings and cancel unneeded sessions.

Try to avoid grooming during a Planning Ceremony unless you plan to do both in one meeting. This almost always leads to the meeting going long and grooming getting rushed. That’s why I recommend the last Grooming Session occur late in the sprint, to limit the window of opportunity for new stories to be inserted at the top of the backlog regularly by a disorganized Customer. The occasional new story is unavoidable, however.

All that said, there are teams that simply set aside the whole first day of the sprint to do all of their grooming and planning. Having facilitated multi-day meetings, I think it is harder to maintain focus that way. But if your team prefers that approach rather than having more interruptions during the sprint, go for it!

Sample Schedules

A team that decided to take a day off between sprints and avoid Monday or Friday ceremonies would start each sprint with a Planning Ceremony on a Thursday, end it with the Demo and Retro sessions on a Tuesday, and take the following day, Wednesday, off. Say your team decided on three-week sprints with a day off in between (14 working days) and Wednesday, May 6, was the earliest you could get the initial grooming done. Your first sprint could start Thursday, May 7, and end on the third Tuesday after that, May 26. Wednesday the 27^th would be a nonsprint day, and the next sprint would start the next day, the 28^th:

Decide against taking a day off, and you can run either a Wednesday-to-Tuesday or Thursday-to-Wednesday schedule.

If your team prefers to follow normal work schedules, you are welcome to choose something simple like the Monday through Friday one with two-week sprints shown below. You will need to adjust your Planning Ceremonies around holidays and work around missing individuals in sprint meetings more often:

Another option I’ve seen combines the two previous schedules such that sprints end on a Thursday, and Friday is a day off from sprint work:

Although the previous two figures show two-week sprints, the same approaches could of course be used with three- or four-week sprints. For one-week sprints, don’t take a day off between.

⇒ Steps:

1. Set Sprint Schedule
2. Schedule Meetings

Create a Quality Mindset

Reasons, not Excuses

In practice, the easiest way to accomplish “No escaped defects” is simple: Fix every defect. Numerous excuses are given for not doing so. Agile is about accountability, not excuses, though; about pleasing customers, not taking the easy way out. Banish the following typical statements from your team’s vocabulary:

• “We’ll fix it later.”
• “The testers will find any problems.”
• “Few people will ever see that.”
• “That bug’s been around forever.”

Some of those lines can lead to a deeper investigation that finds a legitimate reason not to fix a defect. But the standpoint of the customer is the only one that matters. In effect, you will fix defects unless customers cannot possibly be impacted by them, whether or not the customers see them. Specifically, fix the defect as soon as it is found unless it:

• Was only reported by one customer, and the team cannot replicate it (often user error, or caused by something unique to that customer’s environment).
• Would be expensive to fix, was not reported by a customer, and requires such an unusual combination of circumstances that no customer is likely to see it.
• Is old and has not been reported again in a long time, so was probably fixed in later versions without anyone trying to.
• In each of the above cases, could not possibly be a root cause for other defects.

Prepare to Track Defects

Defects are sometimes called “bugs,” especially in software.[9] I like the term. When you are truly dedicated to pleasing customers, defects will bother you like fleas under your collar. In short, per American English slang, defects will “bug” you!

There are both commercial and open source bug applications (such as Bugzilla) designed for recording, tracking, and reporting on defects. However, a digital Agile tracker will likely make it easy to create a defect from within the user story form, automatically link the two, or convert the defect into a user story if desired. It will also likely provide a reporting mechanism that tracks the number of defects, and within-sprint resolution rates for quality improvement. Use stories if your tracker doesn’t have a defects function, and find a way to make them obvious such as a different color or a custom category field.

On a physical storyboard, you can attach sticky notes for defects to their story cards. Use a different color from that used for tasks, but otherwise treat them exactly like tasks. When done, leave them attached for analysis after the sprint. For “standalone” defects not related to a story in a sprint, use a story card of the defect color.

The emphasis on quality is implemented through three practices related to your tracker:

• No story can be accepted if it has a defect associated with it. In other words all tasks and defects must be completed before submitting the story for acceptance.
• Any software standalone defect must get fixed in the sprint after it is found. Its card (physical or virtual) goes to the top of the backlog for planning into the next sprint. For hardware, this may take more than one sprint, but work related to defects get rank-ordered above new development.
• Any backlog of older defects will be eliminated except for those meeting the exceptions in the previous bullet list. This is done by treating them as technical requirements and setting aside part of your capacity in each sprint for clearing them until done.

Set Criticality Levels and Responses

Standalone bugs must be classified as they come in, to determine how quickly they need to be solved. The first question is whether they are actually defects. Customer support professionals will tell you that many complaints come in about problems that in fact are functions working exactly as intended! Either the user is making a mistake, or they just don’t like how the feature works. In those cases, you can decide either to do nothing other than communicate that decision, or can create a user requirement story for consideration by the Customer as part of your normal planning process. Along those lines, some “defects” are actually requests for new functionality. These, too are treated like any other customer requirement.

Anything else is a defect. Next up is whether you have to fix it right away. Again, if the defect was found by the team related to a current-sprint story, the answer is always, “Yes!” For all other bugs, the question is whether it constitutes an emergency which must be fixed immediately.

Your organization may already have a means of classifying defects. Otherwise, have the team create a system with at least two levels of criticality based on the impact of the defect on the user, such as:

1. Makes the product/service/feature unusable.
2. Slows down or otherwise limits the usefulness of the product/service, or a cosmetic defect.

Level 1 defects count as true emergencies, discussed in detail under “Toe the Goal Line.” New Level 2 defects go into the next sprint. Anything else, again, becomes a story or epic for future planning.

Putting all that together results in this decision matrix:

In Sprint?	Level	Tracking and Response
Yes	Not relevant	Tie defect to story. Must be corrected for acceptance.
No	1	Must be done immediately, even if it impacts sprint work. If using placeholder stories for support, add as a task for tracking.
No	2	Place in next sprint.
Yes or No	Not a defect	Create user story in backlog.

The table’s set of responses reflects two concepts from the Agile principles: “Continuous attention to technical excellence…” and “maximizing the amount of work not done…” In FuSca, it contributes majorly to the Performance Standards of 100% story delivery and of zero bugs found by people outside the team.

Nonetheless, if your team wants more levels, that’s your call. Whatever you decide, you’ll need to set up your tracker to reflect them.

Triage and Resolve Defects

When a team member finds a bug, that person will decide whether it is related to a story in the sprint or not. If so, the member creates a defect in the tracker and assigns it to the story. When someone else is working on that story, notify them immediately to ensure they have time to address it within the sprint. The story owners may disagree on the relatedness, in which case those involved should negotiate agreement and escalate quickly to the Team Guide if they can’t.

Teams that provide support for user-reported bugs might want to set up regular “bug triage” meetings of key players. In these, the group makes the decisions shown in the table above once or twice a week, plus on-demand meetings to consider apparent emergencies. Those key roles will vary among teams, but they generally include at least the Team Guide and Architect(s), and perhaps subject-matter experts from the team(s). Each of these roles should have a designated backup so the meeting can go forward without them.

As a Facilitator I have only participated when asked, and then only to facilitate the meeting. The agenda is simple: Review each newly reported bug per the table above and implement the response called for under “Tracking and Response.”

⇒ Steps: Create Quality Process

Create Action Items

Most of your team’s planned actions will be captured in your stories and tasks once your sprints start. Until then, you need a means for tracking actions and driving completion. Even after then, some actions will need to be done outside of the Sprint Plans, for instance to unblock a story so it can be brought into a sprint, or to identify a point of contact for help on a story. These needs are more likely to get filled if you ask for a commitment to an “action item.”

You may already have read about these in the facilitation section under “Self-Directed agile.” As a reminder, each action item must include:

• Task—What must be done, using words specific or measurable enough that everyone will agree when it is “done.”
• Responsible Person—An individual agreeing to perform the work or lead a subteam to do so.
• Report Date—A realistic due date set immediately by the responsible person, at which time they will report the item’s status and set a new date if needed.

Many teams put an action item directly related to a story on its card, often as the reason that item is blocked. When the action item is cleared, the story is unblocked!

Another option is to create a single list of action items, using a spreadsheet or other program that can sort the items by date. Then the Facilitator can check it regularly and follow up with people when items become due.

Although I discussed this last, your first step toward implementing FuSca is to figure out how you will handle these. From now on, when I ask you to create an action item, that includes recording it in whatever means you are using to track them.

⇒ Steps: Prepare for Action Items

↑ The Sprint Process | ← Make Initial Decisions | → Groom Stories

---

[1] Architect, Agile Liaison (AL), Agile Release Manager (ARM).

[2] The “Scaled Agile Framework” or “SAFe” misuses this term for a much larger chunk of work. People certified in that method have admitted to me that is a confusing change from this traditional use of the term.

[3] The person on the team with the most experience and information about a technology, skill, knowledge base, etc.

[4] See “Team Pay for Teamwork” to explore ways to compensate or otherwise reward team-oriented behavior.

[5] This sounds nicer than the more common “hit-by-a-bus” line I formerly used.

[6] See “What is the right size for a Scrum team?”

[7] See “Demonstrate Your Success.”

[8] Described under “Prepare for the New Sprint.”

[9] The term existed prior to the Computer Age—Thomas Edison used it in 1878—but it probably became popular in computing after a malfunction in an early machine was traced to a moth trapped inside.