- Points to Remember
- Choose a Tracker
- Identify Guidance Roles
- Choose a Sprint Cycle
- Create User Stories
- Create a Team Charter
- Schedule Meetings
- Create a Quality Mindset
- Create Action Items
I have an important bit of advice for you:
The transition to Full Stack Scrum™ is like any major change in your life, such as going to college or getting married. It will take more hours, sweat, and hassle than you think it should. (I tell protégées often, “Everything takes longer than it ‘should.’”) At times you will want to give up. After you think you have FuSS™ down cold, frustrating problems will occur. After you have it down, some problems will reoccur!
But you decided to make major changes because you knew they would make your life better in the long run—that the benefits were worth the personal costs. When you get discouraged, re-read the “Benefits of Agile and Scrum” section and just keep going. Research dating back to 2007 by Angela Duckworth at the Univ. of Pennsylvania and other researchers proves that “one personal quality is shared by the most prominent leaders in every field: grit.” They explain that “grit” is “perseverance and passion for long-term goals. Grit entails working strenuously toward challenges, maintaining effort and interest over years despite failure, adversity, and plateaus in progress.”
Sound like fun? Then you’ve got what it takes! Let’s get started.
Some of the release and enterprise work described in other sections will eventually hit a roadblock if the teams involved have not made some progress in learning Scrum. As you are getting the wider efforts under way, in most cases it will make sense to go ahead and begin converting the team(s). And of course, your team may not be doing any of that upper-level change. Either way, that’s why I put this section first, though I prefer clients do some of the stuff in “Structuring for Agile” right away.
The one reason to wait is if the current teams will be reorganized according to the principles listed in that section. Primarily this involves creating fully cross-functional, full-stack teams instead of having, for example, a team of hardware engineers, a team of software testers, etc. It makes no sense to invest time in team decisions that will have to be re-made by the new teams. In that case wait until after the reorganization, and have each create its “team charter” as explained in this before doing anything else. The step sets will remind you to do that.
A key advantage of FuSS is its emphasis on keeping teams productive. That starts at the start! Don’t stop forward progress to make this switch. Existing teams converting to Scrum should continue to work on deliverables using your current project management methods until you are ready to start your first sprint. (A step set will tell you when that is.) New teams can be researching the technology, investigating architecture, and identifying technical requirements while running through the steps to start FuSS.
In either case, get started on choosing how to track you work first. It could take a while, and you can be doing other Scrum-related tasks in parallel. Those of you transitioning one small team can skip directly to “Choose a Tracker.” Everyone else, keep reading.
Coach the Coaches
A staffing agency once contacted me to see if I would be interested in leading an Agile transformation for a statewide insurance company. The insurance company had been struggling with Agile for years. In fact, I had turned down a Scrum Master position there earlier in my career because it was clear they weren’t really adopting the Agile mindset. The agency recruiter assured me the company was making a sincere effort “to change this time.” Yet the job description said this role would be leading a “team of coaches” through the process.
“It sounds like now after years of doing Agile wrong, they are trying to change the wrong way, too,” I said. The recruiter asked, what do you mean? Well, I explained, “they are assuming they need a ‘team of coaches’ before anyone has done a gap analysis to determine what they need!” He saw my point, but said his client wanted to make sure whatever coach they hired “had the resources” to implement the changes. And here I heard the dollar signs popping up in his head. It turns out his company has an “Agile practices” team. The agency would, of course, make more money if it could sell the client a bunch of coaches, necessary or not.
In any but the biggest companies, I consider it a waste of money to hire more than one coach. You already have, or will have, a “team of coaches”: your Scrum Masters! The primary function of that role is to coach the SM’s team, Product Owner, and/or Customer. In FuSS, the Agile Release Managers provide that service at the program level, and other scaled Agile systems have similar roles. You would only need a team of additional coaches if you did a lousy job of training the people who are supposed to be doing the coaching. Your role as the change agent can be thought of as “training the trainers,” a well-established concept in adult learning.
To be clear, I have no objection to hiring an external coach to help you implement FuSS, or any other Agile system… obviously, given that I make my living that way! The coach’s job, though, is to work their way out of a job. Doing that well means leaving behind Scrum teams that can take it from there to run the system—and radically evolve the system, if desired, to keep meeting their and their customers’ needs. Given the power of self-direction, I especially cringe when I see the phrase “Agile Center of Excellence.” Having such nearly guarantees an overly standardized and lasting approach to Agile. FuSS is highly prescriptive at first due to the value of systems thinking, but then teams are free to change processes as long as the organization’s objectives are still met.
Restructure for Agile per “Structuring for Agile”; implement FuSS; tie your performance appraisals to the Agile Performance Standards, if you do appraisals; and your teams will continue to fill the needs behind your conversion to Agile.
Model and Guide Desired Behaviors
Adults learn best by doing, in small chunks of learning at a time. The FuSS step sets incorporate these and other best practices from adult-learning experts, but most sets are focused on someone facilitating meetings with a specific team or program. The FuSS change agent will provide training of those facilitators on what to do, and then follow up to ensure the learning sinks in. You can hire an official Agile Coach if you have the money, and the transformation may go faster in that case if you’re not an experienced trainer. But a goal of this site is to make that unnecessary. By following the step sets in order, almost anyone can help people learn the system.
In programs of four teams or less, I strongly recommend the use of “modeling.” Simply put, this means to demonstrate the skill until the learner expresses a sense of understanding. That done, let the learner try the skill under close supervision, and finally let the learner take over while the coach monitors. This should sound familiar: It is the “Shu-Ha-Ri” model discussed earlier, but from the coach’s perspective.
Specifically, I am suggesting you, the change agent, serve as the initial Scrum Master for each team. One person can handle up to four with a little juggling. After a team is running Scrum smoothly, usually after four to six sprints, help them select their own SM. Slowly shift into the background, attending team meetings to “coach the coach” until the SM seems and feels ready to take over. After that, check in on occasion and remain responsive to questions. Otherwise, you can move on to your next set of teams, or up to release planning; go back to your regular gig; or if a consultant, find your next contract!
When helping a larger number of teams get started all at once, first make your tracker decision. Then gather the teams and lead them through the process at least to the point of their identifying their Scrum Masters and Product Owners. Better is to get through all the sets for “Get the Team(s) Started”; this ensures these critical steps are done correctly, while helping ensure the new SM and PO do not have too much influence over the decisions. (The guidance on project kickoffs shows how to do this in an initial multi-day meeting.) If a single meeting isn’t possible, meet with the teams individually within a short window, two to three weeks, to facilitate them through to that point.
Then set weekly meetings with all of the Scrum Masters to coach them through the remaining steps of the sprint process. At each, let people discuss the efforts from the past week. Next cover the steps for the following week, reviewing the background information under “System” and also walking through the relevant step set(s). Let the group dictate how many sets they think they can do in a week. They should continue with their normal work, but don’t let that be an excuse not to take at least one step (set) forward each week. Keep pushing change like a sports coach, or the momentum may die.
Between training sessions, attend as many team meetings as you can. As defined under “Scrum Ceremonies,” be more of an “observer” than a “participant.” That is, resist the urge to jump in unless the SM says something wrong based on FuSS. Remember that he or she is the coach of the team; you are the coach of the coach. You don’t want to undermine the SM’s position as the Agile expert on the team. After the team begins using a tracker, look at it after sprint planning to review the quality of story grooming, capacity planning, etc. After each Demo, review sprint results.
For issues specific to a particular team, talk to their SM—talk, not e-mail, for reasons explained under “Coach the Team.” Problems that other teams might run into, or did, you can bring up in the next training session without “naming names.” Just say you spotted a problem whose discussion would benefit the whole group, and discuss it without revealing the specific team or details that would identify them. The SM involved is welcome to self-identify, of course, but putting them on the spot will reduce their willingness to cooperate with you in the future.
Once the teams have Scrum down, the most efficient way to get multi-team release planning under way, if relevant, is for you to serve as the initial Agile Release Manager. The entire transformation effort can be derailed if someone mishandles this position. Just as the SM and PO cannot be allowed to think of themselves as bosses of their teams, this person is not the boss of the program. Establishing the role correctly will build in defenses against bad behaviors, because people who have seen it done right will resist—or at least report—actions that cross the line. As when serving as the original SM for the team(s), you can train a replacement and roll off once the Release Planners have the process down, usually after two or three releases.
Obviously, when Scrum started, there were no software programs for running Scrum! It is still fully possible for collocated teams to plan and track Scrum projects using paper stuck to a wall. The biggest advantage of a paper system is the low cost. There is a fun factor, too, in moving story and task cards around.
However, a paper system has major disadvantages compared to a software solution. People outside your physical area cannot check a bulletin board easily, if at all. Stakeholders not in its vicinity will regularly bother team members for status reports. A wall cannot calculate estimates, progress, or historical statistics for you. Stories and tasks are revised often in Scrum, which is easier when they are digital. Because that revising is easier, people are more willing to suggest changes, resulting in higher-quality stories that save a lot of group labor time over multiple sprints.
In teams with offsite members, a paper system means the Scrum Master will have to help them choose tasks and update the board with their status information every day. Offsite members will feel even more out of the loop because they cannot see and manipulate the board. For fully virtual teams, a software system is mandatory. The same is true in regulated industries. You will need records of compliance that would be a nightmare to maintain in paper form.
Given all these reasons, I strongly recommend you choose a software program instead, preferably available online. If your team is small enough, some are free, a great way to try out Scrum without making a large financial commitment. As with any software, of course, the more you pay, the more features and potential value you get. Every commercial tool I’ve used offered a lengthy free or reduced-cost trial period, so don’t be afraid to explore those.
In the rest of this site, I will refer to whatever solution you are using as the “tracker.” Unless I specify different actions depending on whether it is paper or digital, you can do any tracker step I mention in either.
⇒ Steps: Choose Tracker Option
Here is what a storyboard on a wall might look like during a sprint:
The rectangles are user stories, in the form of notecards taped to the wall. Those in the Product Backlog on the left side are in priority order top to bottom and wrapping to the right. (That is, the story at the top of the second column is ranked after the one at the bottom of the first, far-left column.) Nine stories are in the Sprint Plan, meaning the team is working on them in the current sprint. The story cards start out in the “Stories” column and stay there until all tasks are done. The smaller squares are the tasks needed to accomplish each story. After Grooming these small sticky notes were attached to the back of their story cards. When finished in the Planning Ceremony, they were moved to the “Planning” column. Some have been moved into later states, telling us their two stories are in progress. One story’s tasks were “Completed,” but the story is not yet accepted by the customer. One has been completed and “Accepted.” The tasks for those two were returned to the backs of their story cards when the cards were moved.
One of the advanced techniques on this site is the use of releases, which require a “Release Backlog.” That section would look like the Product Backlog, and be placed between the product and sprint backlogs.
Pre-formatted templates and cards are available online, and reusable versions for white boards. But lined note cards or large lined sticky notes will do just fine. You’ll also want some different colors of tape to create the grid.
⇒ Steps: Create a Paper Tracker
Picking a Tool to Try
One of the most common and costly mistakes managers make is to analyze an improvement project by looking at either costs or benefits alone without quantifying the other side. For example, proposed process-improvement or cost-savings projects will predict financial benefits without comparing labor expenses. Tool comparisons look only at costs without considering the relative impacts to productivity. Often, this is because it is far easier to quantify one side or the other of the equation. The money you gain or lose is sometimes hidden: Lost sales or wasted labor hours never show up as line items on a company balance sheet.
Yet they are there. If your organization wastes 2,200 labor hours in a year, that means you have an extra person on your staff just to cover the wasted time. An organization of 80 only needs to waste about 6 minutes per person each day, 1.25%, to add up to that amount of time. I have watched teams lose the equivalent of a week’s worth of one person’s time in a single poorly run Planning Ceremony!
That’s why skilled managers use “cost-benefit analysis” or CBA to look at the total costs of each option versus the total benefits, and choose the solution that provides the biggest net return. One such CBA I ran proved the Agile tracker tool that won would save the company a quarter of a million dollars a year—even if it only provided a 2.83% improvement in team productivity!
This site contains the worksheets and steps you need to perform a robust CBA comparing two or three digital trackers. It may seem daunting upon first read-through, but is easier to perform than it seems, and is the best practice for making a major decision that will impact your bottom line and folks’ satisfaction with Agile. I see no reason to drag out the decision-making, though. Have a couple of people download a few trials, run through the process detailed at “Agile Tracking Tool Comparison,” and come up with an option to try for free. Once you choose a top option, have the whole team try it for a couple of sprints, and if they don’t like it, try the #2 candidate. The overhead of switching tools a couple of times is not terrible assuming you choose tools that can export and import stories via spreadsheets. I’m all for due diligence, but the initial decision should take a few weeks, or at most a few sprints, not months. You can continue with other Scrum decisions at the same time.
If a team in your organization is already using a digital tool, it makes sense to adopt that unless it is missing critical features. The “Tracker Comparison” spreadsheet’s “Totals” tab shows what I consider those to be (those with a weight of 1.25 or higher). As a sign of Agile empowerment, the team or set of teams should be allowed to use whatever application it wants. (Obviously all teams working on the same set of deliverables must use the same application, to facilitate work coordination and progress reporting.) Seek recommendations from people you know who are using Scrum, and conduct a Web search using the term “Agile tool” for options and input.
I’ve always found the Software-as-a-Service (SaaS) option, where users just log into a public Web site, easy and reliable. The better options all meet international standards for security and privacy, which in turn satisfied the IT Department requirements of major corporations I have worked with. Many companies choose tools they can download and host thinking them cheaper. They do not account for the higher amount of administration time to maintain them, not to mention any productivity differences.
I do not recommend trying to force a waterfall tool to handle Scrum. You can drive a screw into a piece of wood with a hammer, but it’s a lot harder and tends to mess up both the screw and the wood. You’re better off using a screwdriver—that is, a tool designed for the job. The same is true for dedicated Agile software.
Another option is to start with a paper method, if your team is collocated, and then choose a software tool after your team has decided it wants to stick with Scrum. One advantage to this approach is that you will have a better understanding of the features when comparing the tools. The obvious disadvantage is that you will have to enter any incomplete stories by hand.
⇒ Steps: Choose a Digital Tracker to Try
Setting Up the Tool
Having set up several tools, some in multiple companies, I can easily say the process will go faster if you have one volunteer take the lead as a tool administrator. Naturally you first have to set the tool up. A “hosted” tool will require you to set up a server, download the software, and configure the “back end” settings that don’t affect what the user sees. With a SaaS you will skip that step. With either choice the admin will need to go through all of the training materials, not just for administrators, but for all functions relevant to your potential users. You will become the go-to expert for how-to questions from everyone. Plus, taking time to become the expert helps you do a better job of deciding how to configure the interface.
Organize the tool by teams, not by work. Remember: You will move work to people, not reorganize people with each new project. Leave the user interface (UI) as it is initially unless something you read on this Web site suggests a change. User questions and team requests are the best guides to UI changes.
Then enter your users. Check to see if the tool allows “single sign on” (SSO)—connecting your e-mail system’s user list to the tools. Next easiest is a feature that allows uploading users from a spreadsheet. You may be able to export folks from the e-mail system, add their team assignments to the spreadsheet, and import them to the tool. In the worst case, you’ll have to hand-enter everybody’s names, e-mail addresses, and team assignments, at minimum. Be aware your action may trigger an automated e-mail to each user. In that case, notify the users ahead of time or many will ignore it as junk mail!
Next comes arranging or providing user training. I have never found the multi-hour sessions sold by the tool providers necessary. I create a “cheat sheet” with the steps most people will need and take an hour to walk them through it with the tool. Assuming the UI is reasonably well designed, most people will figure out the rest. You might do a separate session for the Guidance Role folks after they are chosen, to show them extra functions most users don’t care about.
Finally, recruit and train a backup or two, depending on the size of your organization. You will save yourself some hassle if you set up an e-mail distribution list that goes to all of you, and encourage people to contact that list when they need help instead of the tool help. In my experience, most of the questions are specific to your organization or require tool admin involvement. Having people go straight to you saves everybody time. Work with your tool admin team to respond quickly to all requests, and adoption will go much faster.
With the tool decision made or under way, identify who will fill the two standard team-level Scrum roles, plus a third I treat as a formal role. The Product Owner (PO) is the person who serves as the point of contact for the customer and communicates the direction and scope for the team. The Scrum Master (SM) facilitates all meetings and serves as a coach helping the team stick to its processes. Finally, though in the ideal Agile world a customer interacts regularly with the team, in most organizations a designated internal “Customer” is needed to represent the external customer(s).
Since the teams are self-organizing, these people cannot act in the ways of traditional bosses even if (unfortunately) they retain performance evaluation duties. Hence I refer to these as the “Guidance Roles,” meaning people providing services to the teams, not commands.
In FuSS, there are also some cross-team roles, meaning positions that usually serve multiple teams with an emphasis on release planning. Those are covered in “Plan in Releases,” because in a single or few teams, the duties are usually handled by team members or the roles above. However, they may apply to and be helpful in your situation, and thus are referenced in the relevant step set.
The next three sections provide an overview of each team-level role. Specific tasks for each appear where appropriate throughout other sections.
Although not usually considered a Scrum role, I think every team does better if it can identify a capital-C “Customer” with a direct hotline to the end users of the team’s deliverables. In the classic and best-case scenario, the Customer is a point of contact in a company that is purchasing your deliverables. Then the PO will interact with them to supply the team’s business and market requirements. This works better if there is one Customer for the team, who filters other people’s requirements to the PO.
In most larger organizations the Customer will be someone in your company requesting those deliverables, like a customer-facing product manager, account manager, solutions architect, or program manager. It might be the “project sponsor,” meaning the person who is supplying the money within your organization for the work. Sometimes it is a volunteer representing a group of users for your deliverable. Or it could be a manager not involved in the team’s day to day activities.
The Customer must agree to:
- Meet regularly with the PO to create, review, and rank-order user stories in the Backlog.
- Attend every Demonstration Ceremony.
- Review story deliverables and accept or reject them, preferably throughout the sprint, but during the Demo at latest.
Exception: “Behind-the-scenes” stories that contribute toward a customer delivery but are not of direct interest to the Customer may be left to an internal requester of the work or the PO to accept.
- When invited, attend parts of Grooming Sessions long enough to answer team questions about specific stories.
- Use the tracker to check on progress as needed, rather than asking for status updates from the PO or SM unless needing more details.
- Respond to team member questions about stories in the current sprint within one business day.
Note: These will be rare if proper grooming is done.
In an internal organization that serves a bunch of groups within the company, teams may have trouble identifying a single Customer, so a lot of the burden falls on the Product Owner. In the worst case, the Product Owner becomes the de facto Customer. In this situation, the PO should look for ways to get input from various people who use your deliverables (as suggested later under “Create User Stories”).
Other Agile-at-scale systems raise the “Product Owner” to this position, turning it into a multi-team role, or even create a team of POs. In my experience, teams more easily design solutions and more accurately predict risks, dependencies, and hours when served by a single full-time PO with deep knowledge of the team and familiarity with its technology. The term still applies because the PO owns the team’s specific part of the larger product. When the team doesn’t have its own PO, also, the role’s team-level tasks usually devolve to the SM, raising the likelihood of that person becoming a “team leader” in effect if not name. That said, if you want to call this role the PO and use a different one for the PO role as described below, that’s fine. Just don’t use a term that suggests team leadership.
On an everyday basis, you will probably just refer to the Customer by their job title (“the account manager…”). In the rest of these pages, I will use capital-C “Customer” to refer to this role, and “customer” to an end consumer of your goods or services.
⇒ Steps: Identify Customer
The Product Owner is someone capable of translating nontechnical requirements into the technical or business terminology your team uses. Often the most experienced person on the team, this could also be a business analyst or similar job title. The duties of the PO will not take up the majority of the person’s working time once FuSS is running smoothly. The PO should not be the team manager, or more specifically, the person who evaluates the performance of any of the team members, directly impacts individuals’ pay, or hires and fires members. This will break the “self-organizing” principle of Agile, because most people will defer to the boss, even if only subconsciously.
The PO agrees to:
- Work with the Customer (or in small organizations, customers) and stakeholders to:
- Gather and write requirements, in the form of user stories.
- Put those user stories into an initial order of importance in the backlog.
- Regularly add, revise, delete, and re-order stories in the backlog.
- Serve as the primary point of contact for the team.
- Serve as the funnel for all nonemergency work, and help determine how to accommodate emergencies within a sprint.
- Attend all sprint meetings (“ceremonies”) and Grooming Sessions.
- Serve as a backup for the Scrum Master.
- Represent the team in Release Planning, if used.
In the preferred scenario of one part-time PO per team, the rest of the time the PO takes on sprint tasks like any other team member.
Although often filled by project managers, the Scrum Master role can be held by anyone who likes organizing, manages their time well, and doesn’t mind running meetings. Once the team is up and running, the SM role, too, is a part-time job, usually requiring only an hour or two of extra work per week beyond the time other team members put into the meetings.
The Scrum Master:
- Schedules and runs all sprint ceremonies.
- May run other ad hoc meetings as requested by fellow team members, though that is not required.
- Drives rapid clearing of blockers.
- Searches out and recommends Agile best practices for the team.
- Facilitates and documents team agreements on its policies and Agile practices.
- Coaches the group or individuals on following the team’s practices.
- Creates reports and analyses of team performance (if the tracker doesn’t).
- Is the primary defender of team processes from interference by customers, managers, or others in the company.
- Serves as a backup for the Product Owner.
The team’s manager should start by asking the customer receiving the team’s deliverables, whether an external company or a group within the team’s organization, to provide a Customer. Failing that, the manager can serve in the Customer role. After all, the manager knows what others in the company are demanding from the team! The biggest danger in this is that it puts the Product Owner’s supervisor into regular contact with the teams, making it harder for the PO and team to exercise independent thinking.
The team, being self-organizing, should select its Product Owner and Scrum Master(s). The most senior person on the team in terms of experience or knowledge might not be the best person for either role, depending on their interpersonal and organizational skills. Job title should not be a deciding factor. (The only traditional job title that corresponds perfectly to the PO role is business analyst, because of the depth of knowledge of the customer’s needs and ability to translate those into prioritized requirements.) I would not suggest forcing someone into the role, because unwilling participation always turns into partial participation. You need someone willing and able to make the role their top priority, setting aside enough time to do the duties as described.
For more than 20 years, I have trained self-directed work teams to rotate the SM-like facilitator/coach role. This prevents the facilitator from being seen as the team leader, and spreads around the administrative overhead. Plus, the other team members will be more cooperative when they understand the challenges of the role! Another option is to rotate it only among those willing to take it on.
Teams willing to rotate the Scrum Master role need only determine the frequency and which people are willing to do it. Certainly the same person should hold the role at least one sprint, and regardless of the length, I would make the switch at a change of sprint. For teams using releases, the end of each might be the best changeover point.
Failing that, ask for a volunteer from within the team, subject to approval by the rest of the team. On a team I trained at NetApp, there was prolonged silence when I asked for someone to step up. Experienced team members stared resolutely at the table. Finally, a guy two years out of college tentatively raised his hand, and said he “kinda liked” running meetings. I asked if that was okay with everyone else, and got enthusiastic head nods from the company lifers!
Another option is transitioning from within (or hiring) someone to be a full-time Scrum Master serving three to four teams at once. I don’t like that as much, because of possible scheduling and priority conflicts between the teams, and because the SM does not gain as deep a knowledge of any of the teams. Whatever you do, do not hire someone to serve as the full-time Scrum Master for a single team: You will be wasting your money, and that person will try to fill the extra time by making decisions the team is supposed to make.
Sharing or rotation within the team is a bad idea for the PO role, especially if you do not have an external customer. The POs may have different priorities, so you are setting yourself up either for conflicts or for unnecessary changes of direction. For similar reasons, I do not recommend sharing a PO across teams.
Some companies combine the Product Owner and Scrum Master roles, but I strongly recommend against it. Not only does this take a big chunk of time from the person’s other duties, there are more important reasons. The PO and SM serve as a check-and-balance, reminding each other of the responsibilities and limitations of each role. If the PO starts acting like a boss, the SM can rein him or her in, and vice versa. Along those lines, it is natural for team members to see someone with duties normally associated with a manager as the manager, so splitting those duties between the roles cuts down on that tendency. The more power you concentrate in one person, the less the team will feel “self-organizing,” thus reducing the benefits you get from empowered teamwork.
The seminal work by two of software Scrum’s originators, Agile Software Development with Scrum, insisted that 30 calendar days was the right number for a sprint. As Scrum spread and evolved, people came to understand every team faces a unique set of factors that can influence this decision. I have seen sprint lengths from one week to four weeks work well.
In any length of sprint, most teams struggle to make their stories small enough to complete within one sprint, so I don’t consider this a major factor in the decision. This seems weird: A two-week team struggles to create two-week stories, yet a four-week team has the same problem with four-week stories! I suppose that is more evidence supporting the studies about people consistently underestimating how long something will take.
True, the shorter the length of sprint, the harder “right-sizing” will be. Plus, the normal delays of waiting for responses from other people, people taking time off or being out sick, and so on, take up a bigger percentage of the overall time in a shorter sprint. Still, for a team I trained that provided direct support to utilities using its data management services, deliveries every week made perfect sense!
Their example illustrates that the longer the sprint cycle, the longer you wait to deliver value to the customer and change processes via the Retrospectives. Also, many people who tried four-week sprints say they lose momentum or a sense of urgency. That fits what I wrote earlier about the value of deadline pressure for speeding up output.
The big-data study I mentioned under “Agile 101” found:
- “Teams using two-week iterations have the best balanced performance.”
- “Longer iterations correlate with higher Quality.”
- “Shorter iterations correlate with higher Productivity and Responsiveness.”
The majority, but not all, teams I worked with settled on two- or three-week sprints as a good compromise. But that may not be true for your team. Here are some considerations to talk through when choosing a sprint length:
- What does the Customer prefer?—This should carry a lot of weight. Shorter cycles mean more meetings per calendar month for them (though the overall time commitment does not go up much). Longer cycles mean fewer chances to see output or to change the team’s direction.
- How long do your deliverables typically take?—If you have some data on your cycle time, or even a gut-level guess, that may suggest your team’s “natural” rhythm. For example, if you know on average it takes 3.3 weeks to deliver a requirement (or “work package” in traditional project management), that would argue for three- or four-week sprints.
- What are other Agile teams in your world doing?—If teams you cooperate with—in or outside of your company—use some form of Agile that has regular iterations, aligning your sprints with their cycles will ease that collaboration. Of course, in the case of teams sharing a Customer, PO, or SM, using the exact same schedule increases the odds of schedule conflicts and burnout. Fortunately, having the same sprint lengths and a near overlap of schedules is good enough. Note, however, that teams in the same program using FuSS can be on any cycle or schedule they want. You’ll learn techniques for coordination despite differences elsewhere on the site.
My easiest advice is, pick a schedule and try it. You can use different lengths the first few sprints before settling on one. But you want to settle on a cycle as soon as possible, because that is the only way to develop a velocity figure that helps to prevent overcommitments and creates some longer-term predictability. (“Velocity” is the minimum number of stories the team gets accepted most sprints.)
All you need to decide at this point is how long your cycles will be at first. The sprint length is important now because the people in the Guidance Roles need to know how big to make the user stories.
The Customer and PO 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 there 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.
There are four types of requirements in FuSS, drawn from standard practices in product and program management:
- Customer/User—Functions and features requested by a customer for 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 is to ensure they get identified and done. When converting organizations to Scrum, I almost always get questions like these:
- How do we make room for innovation?
- What about other needs, like documentation?
- How do we handle legacy bugs 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:
The next four subsections explain each type in detail.
Customer or User Requirements
Sit down with the customer(s) and develop a list of 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 Product Owner 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 bugs 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. 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.
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.
One of the most consistent complaints I’ve heard in a variety of industries (including prior careers) 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 customer or the needs of the business. Just when a release manager thinks he or she has 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
- 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 ensure these needs are identified in the project plan, in multi-team programs the Agile Release Manager is responsible for ensuring all are covered in the Product Backlog. However, he or she 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 in FuSS 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.
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 is more reliable, but takes longer to put in and costs more, increasing manufacturing costs. All of these must be decided even though the end user couldn’t care less about it.
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 tracking dates 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.
One of the classic “use case” requirement formats from product management is:
FuSS, 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 (for details, see “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.
As described already, an “epic” is a requirement that takes more than one sprint to complete. 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 the Release.”
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 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 will be safe and dry.
- 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.
- Look for instructions on the Web and the home store.
- Decide which option to use.
- Write down the supplies I will need.
- Discuss the results with my better half.
- 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.
- Purchase the supplies.
- Build the frame.
- Mix, pour, and smooth the concrete.
- Test for level and hardness (after curing).
- File flat if needed.
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 FuSS 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.”
In disorganized organizations, teams or critical team members are regularly pulled into unexpected meetings. They may often get sent off to “fight fires.” 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 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 SM 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.
- 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:
- Create a new task named for the request (with no estimate of labor hours).
- Track the burndown of to-do hours (and actuals if the team tracks those) in the placeholder task (see “Tracking Progress”).
- Track the status in the new task.
- 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.
When a subject-matter expert (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. 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?” 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 this 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 his or her big shoes than if they were starting from scratch.
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:
- Create test case.
- Write the code.
- Perform unit test.
- Perform code review.
- Perform QA.
- Fix bugs.
- Update documentation.
Another advantage of a digital over a paper tracker is you can set up “template” stories 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
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” with at least the following:
- Team Name—What does the team want to call itself? Let the members choose. This is an easy way to instill some fun and build a sense of team identity. Insisting that the name reflect a particular function, instead, goes against the concept of cross-functional teams that could take different work. Members can choose to stick with a functional name, but usually humor takes priority!
- Mission—What purpose does the team fill, or what ultimately does it seek to accomplish for its customers, organization, or itself? This should be one short, memorable sentence.
- Rules or Values—What behaviors do team members expect each other to follow when interacting? Though this can be organized by values such as “Honesty” or “Accountability,” the list should specify the actions and types of words members should be using.
You may be surprised at how easy these are to identify. I have run the exercise to create this list with teams that were primarily Hispanic, primarily Indian, and primarily Anglo-American. A lot of the rules they came up with were strikingly similar, and those that differed seemed more related to company cultural history than national or ethnic culture. That is, they are reactions to patterns of behaviors the team members have experienced in their organizations—and don’t like.
- Meeting Rules—What behaviors must be followed during team meetings? This is covered in detail under “Set Meeting Rules.”
- Self-Enforcement—When one member thinks another has violated a team norm, what does the rest of the team agree he or she should do to raise the issue? If that doesn’t work, what should the members involved in the disagreement do next? These steps are critical to self-organization. Being empowered means you don’t run to a manager to solve these problems, unless you can’t fix them as a team.
- Core Hours—What times of day do all members agree to be available on normal workdays? This allows individual flexibility on working hours while also assuring members can count on access to each other for a predictable part of each day. Ask, “By what time are we all at work? And what is the earliest time anyone leaves regularly?” For collocated teams in the United States, 10 a.m. to 3 p.m. is a fairly typical set of core hours, allowing time for parents to get children to and from school. Virtual teams I’ve worked with tried to overlap by at least half a day, though sometimes this required some members to work earlier or later than typical working hours. In most cases they worked from home, so this was not a problem. And sometimes the team knew a member would usually be gone the same hour each day, for example to take a kid to school.
- Processes—What team-specific policy and process decisions have members made together? These include customizations and choices made within organizational policies and processes, and for FuSS, the decisions left to the team. Recording them reduces later confusion or redundant conversations about what was decided.
Though the concept is not exclusive to Agile, science suggests that creating a Team Charter with at least the sections above facilitates high team performance. In most cases it takes just a few hours of team meetings, and less if the team has already been together for a while. Like the Agile documentation discussed throughout the site, a team charter is just light paragraphs and bullet lists, not a tome. It does not have to be a document file. It, or some of the sections, can be on an intranet page or wiki. Just get the information written down somewhere accessible to team members, and prevent nonmembers from editing it.
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 Scrum Master 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.”
This topic is covered extensively under “Mission” and “Rules/Values” in The SuddenTeams™ Program. However, in the step sets linked below, I have copied the relevant actions with some Agile modifications.
I was surprised to come across a number of studies showing that people do not mind meetings if they feel their time was well-used and that changes result from that investment. Through a combination of research and trial-and-error over two decades, I have developed a set of rules proven to achieve those goals. They help make meetings efficient by reducing time-wasting behaviors, and ensure decisions lead to actions.
By the way, I do not hold any team or program meeting that will not result in decisions. This was true even before I learned about Agile. I have never held “status” or “information-only” meetings. Status is more efficiently relayed by other means, in FuSS via the tracker. Information can be doled out as part of other meetings and reinforced via e-mail and intranet, rather than being stored up until it becomes the point of the meeting. (Note that I do not call a training session a “meeting.”) A major step toward efficient meetings is to only hold one when a decision is required. Daily Standups count because each person’s choice of what to work on that day is validated by the rest of the team, which is a decision. That, I suppose is my First Rule of Meetings.
Ask the team to follow the rules below for the first three months, and negotiate any others members want. After three months, the list can be modified in a Retro Session like any other part of your team processes:
- All members are equal—From now on, your job title, place in the company’s hierarchy, years on the job, and expertise do not give you any special power during team meetings. Perspectives from outside your function will help you and the team see your function more clearly and to innovate. Functional and tenure diversity are believed to improve team performance for that reason.
- No side conversations—You know how during meetings these two people over here will start talking, then these three, and so on? What happens to the meeting? It grinds to a halt. Usually, people are either A) exchanging thoughts that would be helpful to the whole group, or B) talking about things that have nothing to do with the meeting, a symptom that the meeting is off track. In either case, they are not contributing to the group. For the sake of everyone else in the meeting, the facilitator must politely interrupt any side conversations. If as a participant you feel the need for a sidebar, decide what it is that you want to tell the group: either information helpful to the discussion, or your concern that the meeting has gotten off track.
- No electronics—During team meetings, your teammates deserve your full attention and energy. Otherwise they lose the power of group decision-making detailed elsewhere in this site. Any other business can wait an hour or two. For virtual teams, this rule becomes, “No other work—meaning no phone calls, other technical work, e-mailing, texting, or instant messaging.” Be in the meeting.
- One subject at a time—If a new subject comes up, write it down for discussion later if it is not on the agenda already. Facilitators will sometimes do this in a section of a whiteboard labeled the “Parking Lot.”
- No backtracking—Once a decision is made, do not let someone go back to it unless there is a compelling reason, like they realized the decision violated a company policy or they have new facts.
- No decision without an action—Every decision must end with an Action Item (detailed later), a task, a user story, or an update to any of those. Even if the decision is to not make a decision, there is almost always someone who must be informed unless they are in the room at the time.
- Understand before you decide—This is based on one of Stephen Covey’s Seven Habits of Highly Effective People. Really listen to other people before you speak, and ask questions if you do not understand their position. Otherwise, attacking it will probably waste time and certainly cause ill will.
Another rule I strongly recommend for every team eventually is, “Silence or absence equals consensus.” In other words, team meetings are the only proper time and place for negative discussions of team issues. If you do not speak up in the meeting, you give up the right to complain. This is vital to developing trust among members. Introverts need only ask for time to think about the decision before final approval. In that case, postpone approval at least until later in the meeting, or to the next meeting if possible.
As for the absence part, you will never accomplish anything if you are constantly waiting for “so-and-so” to be there, because there will often be a so-and-so missing. It is okay to delay noncritical decisions to get information from an expert. But at some point, you have to move on. If you are the person not at a meeting when a decision is made, you need to support whatever the team decides unless, again, you have a compelling reason to backtrack.
Bear in mind that “consensus” does not mean “unanimous agreement.” It just means every person is willing to implement the decision, whether or not they fully agree with it. A healthy team will not reach unanimous agreement on all the big issues. The claim “conflict is good” takes this point too far, and is scientifically false: Repeated studies have shown that when confrontation turns into either personal or technical conflict, it harms team performance. (Most of the rules above exist to prevent the causes of conflict.) But open debate is critical to making good decisions. Falling into “groupthink,” where everyone just goes along to move on, throws away the value of multiple perspectives and discussion time.
On the other hand, if debaters never give in, no decisions will ever be made. Consensus is a healthy balance between endless debate and “groupthink.” It requires a willingness to drop your ego when you’ve run out of logical ammunition. Even if you think the team is making a mistake, once you have lost the argument and have no other facts to present, help the team “make the mistake.” You will gain credibility whether you turn out to be right or not, because the team will know you aren’t just arguing for ego-based reasons. That extra credibility will increase your persuasiveness in the future (per the “Recipe for Persuasion”).
Unfortunately, in some companies, this is not a realistic rule at the beginning. Some ethnic cultures place great emphasis on hierarchy, so team members have been trained from birth to tell anyone with a leader-like role what they want to hear. (That is not a stereotype or criticism: I am summarizing what people in those cultures have said when objecting to this rule, not to mention anthropology research.) Worse, many organizations, regardless of country, have created cultures in which people get emotionally beaten up if they question authority.
In cases of teams objecting to the rule for these environmental reasons, I tell members to set a goal to implement this rule within six months of the first Planning Ceremony. During that time, the SM should individually call on people to express opinions or consent, and ensure others in the meeting listen to those people without interrupting. Over time, as specific members become more outspoken, ask them privately if you can stop calling on them and assume their consensus when they don’t speak up. Even after implementing the rule, though, you may still need to call on quiet members on occasion. You’ll be surprised how often someone has a good question they could not make themselves ask!
⇒ Steps: Set Meeting Rules
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. The first story took a high-school robotics team I taught Scrum 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
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:
|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. 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 30–60 minutes as late as possible in the day. The length depends on how many of your stories will be relevant to stakeholders.||Consult with your stakeholders on times they are usually available. Start with a longer length if unsure how much time you need.|
|Retrospective Ceremony||Right after the “Demo” every sprint, for 60 minutes initially.||Only team members (including the PO and SM) are allowed. Some teams cut the length in half as they mature.|
|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 for members’ input 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 SM or PO—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 between 5 p.m. and 8 p.m. their local 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 SM more time to do some administrative work. And it allows the PO 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 the sprint ceremonies to begin the first appropriate day after you will complete your initial grooming sessions. Upon negotiating a preferred schedule with the team, the SM 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.
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 Table 3 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 SM 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 regular 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!
⇒ Steps: Set Meeting Schedule
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 27th would be a nonsprint day, and the next sprint would start the next day, the 28th:
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: Set Sprint Schedule
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.
Defects are sometimes called “bugs,” especially in software. I like the term. When you are truly dedicated to pleasing customers, defects will bother you like fleas under your collar. In short, 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 to clearing them until done.
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:
- Makes the product/service/feature unusable.
- 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|
|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 FuSS, 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.
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, he or she 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 Product Owner 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 Table 4 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 Product Owner 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 Scrum Master 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
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.” 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.
- Due Date—A realistic due date set immediately by the responsible person.
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 Scrum Master can check it regularly and follow up with people when items become due.
Although I discussed this last, your first step toward implementing Scrum 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
 Duckworth 2007.
 Let’s get the obvious joke out of the way: No, this does not mean “sado-masochist!” Sometimes team members think the SM is the former, though, and the SM thinks themselves the latter!
 Maccherone 2014.
 Architect, Agile Liaison (AL), Agile Release Manager (ARM).
 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.
 The person on the team with the most experience and information about a technology, skill, knowledge base, etc.
 This sounds nicer than the more common “hit-by-a-bus” line I formerly used.
 For example: Rogelberg, Leach, Warr,& Burnfield 2006.
 Text adapted from SuddenTeams.
 Covey 1990.
 Described under “Prepare for the New Sprint.”
 The term was used 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.