Contents

• No One Way
• Sprints
• The User Story
• Scrum Ceremonies
• Tracking Progress
• Daily Tasks of Scrum
• Guidance Roles
• Blocks to Progress
• Multiple Layers of Quality
• Low Cost Release Planning

---

No One Way

There are many different approaches to implementing Agile, such as Crystal, Extreme Programming (XP), and Rational Unified Process. Some are more focused on people’s interactions, while others are more technical. In practice, smart Agile coaches borrow liberally from the different approaches to blend a mix that best suits a specific project’s environment and needs. But it helps to start with one method, get that running smoothly, and then go hunting for new techniques to address specific situations.

Scrum is arguably the most popular approach. The word “scrum” refers to a big huddle of players on both teams in the sport of rugby, pictured above. While drafting this site in a coffee shop, I chanced to meet members of the women’s rugby club from North Carolina State University. They explained that after a rules violation, eight players on each team gather and link up arm-to-arm. The teams then link with each other head-to-head, the ball is thrown underneath the scrum, and everyone uses their legs to try to push the ball out to a player on their team.

A member of the Wolfpack added something she said would make sense for this site. “The tighter and stronger the scrum is, the better it works,” she said. So true! Scrum is a method for getting teams to work tighter together and thus be stronger. By “team” I refer to a small group, at least three and preferably no more than eight people, with a mix of skill sets and roles but a common responsibility or purpose.[1]

Very little in Scrum is required. Ken Schwaber and Mike Beedle laid out some basic concepts, principles, roles and meetings in their seminal book, Agile Software Development with Scrum.[2] But Scrum has evolved in many ways, as captured in The Scrum Guide by Schwaber and co-creator Jeff Sutherland. More importantly, it is expressly defined in that guide as a framework, not a method. The method I present here is one way to do Scrum, not the one way. Some Scrum coaches will disagree strongly with parts of my method. But it is informed by my more than two decades of working with empowered teams and reading of hundreds of related studies. Most importantly, it has proven reliable for moving teams quickly from waterfall or no project management to delivering consistently on their promises in as few as three months. This has been true for dozens of teams across multiple companies. Nonetheless, please bear in mind that statements I make about “Scrum” refer to my method, not necessarily Scrum in every instance.

This topic, “An Overview of Scrum,” takes you through the basics of generic Scrum while pointing out some specifics of FuSca. The goal is to introduce the system and provide information for evangelizing its adoption within your organization. It is not intended to give you all the information you will need to implement the system. Later sections take you through everything here in greater detail.

Sprints

In Scrum, an iteration or “sprint” is a short period of time in which the team tries to plan, design and deliver a set of working, fully tested deliverables. Each sprint is intended to result in a “potentially releasable (or shippable) product.” That is, whether or not you choose for business reasons to release the output to a customer, you could. The output is fully developed, tested, bug-fixed, and documented. For new or non-software projects, the output at least is tangible—not just ideas, for example, but documented decisions—and could be shown to a customer for comment. The sprint lasts one to four weeks, and sprints are repeated until the customer says the project is done. Once a team settles on a good sprint length for its circumstances, it should not change the cycle again without very good reasons. By sticking to one sprint length, the number and quality of deliverables the team can produce in a sprint becomes more predictable.

The User Story

The basic unit of work in Scrum, adopted from Extreme Programming, is the “user story.” The story captures a requirement similar to an old-fashioned “use case.” A standard user story format is:

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

This format makes sure the team members are focused on the customer, understand what the customer wants, and know why it is important. Often knowing the purpose can influence the final design of a deliverable. The story also serves as a means for communicating with a customer on those points. In the ideal Agile situation, that person is an actual customer outside the company. More often they are someone inside the company who gets requirements from external customers, such as an account manager, product manager, or business analyst.

As you may have gathered, a critical difference between typical project requirements and user stories is that each story must be small enough to complete within a sprint. Indeed, a team will typically tackle multiple stories within a sprint in order to keep everyone busy. (We’ll discuss larger types of requirements called “epics” later.)

User stories may be recorded on note cards stored on a vertical surface like a bulletin board or whiteboard someplace where everyone on the team can easily see them. Some Agile teams sit together in the same room at least part time—often called a “commons,” “team room,” or “war room”—in which case a story board would be on a wall there. Software applications for managing Agile projects typically re-create a paper story board. They can display stories as icons that look like note cards; in text rows in tables; or the user’s choice of either. When I use the word “story” on this site, I will mean the three-part story statement. I’ll add the word “card” in reference to tracking the story within your tool, whether that is recorded on a physical note card or a digital representation.

Each story also needs “Acceptance Criteria.” This is a short statement, preferably measurable, by which the team can prove to the customer or their representative that the team achieved what it was supposed to. In FuSca it gets added below the story on the story card, which may also include high-level technical notes, risks, and dependencies.

Many teams assign “story points” as a size estimate, often using the first of a set of numbers called the “Fibonacci Sequence”: 1, 2, 3, 5, 8, and 13. Points do not measure anything. They express the Scrum team’s educated guess as to how big a story is compared to any other story. The size is not just a function of the mass of work, but also its complexity and/or risk, so this is not a time estimate in the waterfall sense. The sizing will vary from team to team, and thus cannot be used to compare team output or pace.

In a major departure from most Agile coaches, I no longer use points in my system. I mention them here because people who are familiar with Scrum will be expecting them. (For an explanation of my reversal on points, see “Why use story counts instead of story points?”) Also, teams already using Scrum with stable story point velocities can implement the FuSca release planning methods without changing from that.

Put all that together, and you might end up with a story card like this:

Stories are stored initially in a section of the story board or application called the “Product Backlog.” This is the collection of all stories the team thinks as of now will need to be delivered at some point in the project, but not yet assigned to a time period. Those at the top are stored in the order they are likely to get done. However, the Product Backlog is regularly revised such that it may look completely different within weeks of starting the project. Stories are added, revised, deleted, and re-ordered regularly until scheduled into a sprint.

Scrum Ceremonies

Scrum teams regularly meet to plan and review their work. This occurs in five types of meetings, often called “ceremonies,” that teams may schedule in different ways:

• Grooming Sessions—In these, the team develops a thorough understanding of each story and, in FuSca, a draft set of the tasks needed to complete it. This session can be a regularly scheduled meeting or scheduled as needed. Many teams conduct “grooming” during the Planning Ceremony instead, the more traditional approach.
• Planning Ceremony—On the first day of a sprint in Full Scale agile, the team members meet to:
  • Determine what stories they will commit to completing in the sprint.
  • Finalize and volunteer for tasks.
  • Estimate how long each task will take in labor hours.
  • Ensure they are not committing to more labor hours than each member has available during the sprint, and reduce the story commitment if needed.
• Daily Standup Meeting or “Scrum”—Every day between the Planning and Demonstration ceremonies, the team holds a very short meeting where, originally and still in FuSca, each member answers only these three questions:
  • What did you do since our last meeting?
  • What do you plan on doing before the next meeting?
  • Do you have any “blockers”—human or technical reasons you cannot complete a task?
• Demonstration Ceremony—On the last day of the sprint, the team shows what it accomplished to the customer and interested stakeholders to get input for future work.
• Sprint Retrospective—The team looks back on the sprint to answer under FuSca these three questions:
  • What went right in the sprint, in terms of results, process, or teamwork?
  • What went wrong in the sprint?
  • What should we do differently in the next sprint?

In Full Scale agile, the sprint starts when the Planning Ceremony ends, and usually ends when the “Demo” begins. Some teams take a day off between the two, meaning for example that a “four-week” sprint is really three weeks and four working days (19 labor days). Regardless, the cycle starts all over with the next Planning Ceremony. This figure summarizes the sprint meetings:

The customer—and technically, anybody in your company—is free to attend any meeting except the Retrospective, and is expected at the Demonstration Ceremony. During grooming, and of course the “Demo,” the customer is considered to be a source of vital information and thus a full “participant.” In all other cases, they and anyone else not on the team is only an “observer” and will be politely reminded not to speak unless asked a question. In trainings I jokingly refer to the old saying that children “should not speak unless spoken to.”[3] Along with the limited questions in the Daily Standups and “Retros,” this is a way Scrum keeps its meetings as short as possible and builds team cohesion.

Tracking Progress

There are a number of standard reports and charts used in tracking Scrum team progress. The primary indicator is the “Burndown Chart.” This is a bar or line chart showing how many tasks or labor hours are yet incomplete in the sprint, and possibly how many stories have been accepted (see the figure below).

In FuSca, during each Planning Ceremony, the team agrees on a final list of tasks, volunteers for them, and applies labor-hour estimates to each. The Burndown Chart totals those estimates and calculates how many hours must be completed each day of the sprint to finish them all by the end, portrayed using an “ideal burndown line.” Each day, team members estimate how much time they think is left on the tasks they work on. The chart compares the total of these “to-do” hours to the ideal line.

To use an overly simple example: If you estimated 100 hours’ worth of work and used a two-week sprint (10 working days), the ideal burndown line would drop by 10 hours per day. Say after Day 3 the members had reduced the total remaining by 30 hours, regardless of how many labor hours that took them. The bar for that day would be touching the line, indicating good progress. If they only reduced it by 23 hours, it would be seven hours over the line. This would indicate the team is in danger of leaving some stories incomplete by the end of the sprint.

This nearly ideal Burndown Chart shows the actual results achieved in a sprint by a software team I worked with[4]:

The darker bars on the left are remaining to-do hours, and the ones on the right are the total story points of completed stories (this company used points). The team hit the work hard on Day 1, kept steadily at it throughout the sprint, and only added a few tasks near the middle, meaning they had done a good job of thinking through the tasks during grooming and planning. The estimated hours for the added tasks explain the protruding bar on Day 8. Because their estimates were conservative, those additions did not prevent members from completing all of their original and added hours, and therefore they completed all of their stories.

Daily Tasks of Scrum

I think one advantage to Scrum is that each day each team member gets to choose what they are going to work on. At the same time, the other team members get better visibility into those choices, and thus can provide input when those choices impact their own. Everyone also can easily see whether progress is being made on tasks they need done. If Joaquin is waiting on Terrance to complete a task so Joaquin can start on one of his, he knows to bring it up when nothing has been done a week into a sprint and Terrance says nothing about it in the scrum. (When I capitalize “Scrum” I am referring to the method; in lower case, “scrum” is just an alternate term for the Daily Standup meeting.)

The overhead for this is really low for the individual team member. At the start of the day, you might look at a list of your tasks to decide what sprint work to do, and you dive in on the task of choice when ready. Before or during your scrum, to make sure the Burndown Chart is up-to-date, you would go to the story board or application. For each task you worked on since the last ceremony, in FuSca you would update:

• The state of the task, such as “In Progress” or “Review.”
• How many hours you think are left (the “to-do” hours).

During the Daily Standup, other members may ask you to focus on tasks they are waiting on, but of course you have the same right. If anyone is falling behind in their sprint hours, you and your teammates have the right to ask why. Ultimately, though, what sprint work you do on a given day, and when in the day you do it, is up to you. People unaccustomed to others knowing what they do each day have objected that Scrum micromanages them. I think this day-to-day freedom, and the fact members create and take accountability for tasks themselves instead of having those imposed by managers, disproves this objection.

Guidance Roles

Team Members with Extra Duties

Typically Scrum defines only two specific roles. The “Product Owner” (PO) serves as the voice of the customer in the customer’s absence and ensures the project delivers value for both the customer and the company. The PO has primary responsibility for gathering customer requirements, converting them into user stories, and prioritizing those stories. Although other schemes can be used, the primary method is the “rank order” of the stories in the Product Backlog. The team does its grooming and planning by working from the top of the backlog down. The PO is a full member of the team and participates in all of the meetings including the Retrospective. This role is often filled by a product manager or business analyst.

The “Scrum Master” (SM) is the meeting facilitator and helps the team follow the processes it has agreed to. Also, if a blocker is identified in a Daily Standup, ensuring it is addressed quickly becomes the SM’s top priority. Either the PO, the SM, or both will handle any traditional project manager duties still required in Scrum that cannot be covered by other team members via user stories.

Note that in FuSca, unlike other approaches to Scrum, each of these are part-time roles, not full-time jobs. The PO will spend most of their time performing that person’s job-title work (such as business analysis). Most of the SM’s duties takes place during the ceremonies, which the SM would have to attend anyway. Team members usually clear their own blockers. Thus the SM preferably is a member of the team with other primary duties who also handles the SM role. In fact, I call for the role to be rotated among all team members. Having a full-time SM, even if working with three or four teams at once, causes that person to be seen as the team leader. Hiring an SM for a single team is a waste of company money and guarantees the SM will do things to keep busy that they should not be doing for an empowered team.

To illustrate, I downloaded a checklist of the things one consultant thinks a Scrum Master should do beyond the meeting facilitation and blocker-clearing all Scrum writers agree are part of the job.[5] It is referenced by some Agile writers as a justification for one full-time SM per team. I went through it to see how many items I could identify as amenable by one of these short-term or part-time fixes:

• Fixable with one-time formal training by the SM or someone else (like a tool administrator), with minor coaching afterward.
• Caused by poorly enforced processes, mostly fixed during ceremonies through better discipline.
• Problems resulting from poor team organization prior to starting Scrum work, prevented or fixed by running one-off exercises provided on this site.
• A problem a good coach can usually solve with one conversation.
• A problem no one SM can solve by themselves because they are shared across teams, thus requiring only a part-time effort by each.

The answer was, “all of them.” One entire section of that blog post is clearly “shared” and, in most larger organizations, would be driven by a cross-team facilitator or enterprise coach. Furthermore, most of the above actions should be done during Scrum ceremonies the SM would have to attend anyway, or through continuous improvement user stories during the early sprints. All of the checklist items are addressed during a FuSca implementation, most prior to starting sprints, and have been handled without issue by part-time or multi-team SMs I trained. Granted, much more of the SM’s time is dedicated to learning the system in the first few sprints, but that is true of everyone on the team—and hardly justifies a permanent full-time SM for the team.

This comes back to the critical point that neither the Product Owner nor the Scrum Master must be seen as the “boss” of the team. Per the Agile Manifesto, Scrum teams are self-organizing. In FuSca, the PO and SM are equal members of the team with everyone else. They only have additional authority in very specific and limited areas. The PO can override team decisions on priority and story completion on behalf of the customer, and the SM must take control of meetings and hold members accountable to the team’s practices. But otherwise everyone has an equal voice, and thus equal responsibility for the team’s successes and failures. The team is supposed to be a “one person, one vote” democracy for most decisions. In fact, the PO role is renamed the “Team Guide” in FuSca to emphasize that the entire team owns the product, not just one person, and that person is not the boss of the team.

Partly for those reasons, also, the Scrum Master is called a “Facilitator” in Full Scale agile. This was the term used by pre-Manifesto self-directed work teams for the equivalent role, and better expresses the limited duties of someone who truly believes in trusting motivated individuals to self-organize their teams. Perhaps more importantly, it removes a potential barrier to comfort with Scrum for some people. The word “master” is a male term, possibly troubling for women and people with other gender identifications. It also has a horrible history for African-Americans and Native Americans, having been one term for slave owners who imprisoned, tortured, and stole the labor of their ancestors. However, to avoid confusion, I still use the terms PO and SM on this site when referring to the position as it is typically practiced in other Scrum-based methods.

Cross-Team Roles

For multiple-team programs that deliver work in multi-sprint “releases,” FuSca has a few additional roles:

• Customer (with a capital “C”)—A customer-facing job title such as a product manager or solution architect who fulfills the customer duties in companies too large for actual customer(s) to participate in Agile planning. (A single team may need an official Customer, too, if more than one person provides it with requirements.)[6]
• Agile Release Manager—Equivalent to the Facilitator (Scrum Master) role, but for release planning meetings and cross-team blockers.
• Architect—A subject-matter expert who provides technical guidance to all teams, often filled by system architects and former functional managers.
• Agile Liaison—A representative of non-Agile or third-party organizations that provide support to, or need something from, the Agile teams.

A program only needs one Agile Release Manager, and if the programs are small, that person can handle more than one. (In this context, a “program” is both the work and the people doing it to support a major initiative, product, or service, usually over years and requiring multiple projects.) Most programs large enough to need release planning will have more than one person in each of the other roles. The first three roles must be assigned full-time to the program(s) they support, just like the teams. The Agile Liaison role is filled by someone in another organization, so by definition that person only participates part-time and may support multiple programs.

You may be thinking a role is missing: Agile Coach. Speaking as someone who often holds that job title, I do not believe in permanent Agile Coach positions. When Agile is running smoothly, only minor corrective coaching is needed, easily handled by the Facilitators, Agile Release Manager, or equivalent in other systems if the teams don’t self-correct. Furthermore, given that the primary job of a modern manager is to coach their employees, in a company that has fully embraced agility, every manager is an Agile Coach! Unlike a sports coach, the job of any business coach is to work their way out of a job.

Blocks to Progress

Scrum makes it easy to identify when something is preventing work from moving forward. A “blocker” or “impediment” may be:

• A technical issue that must be resolved for a story or task to be completed.
• A dependency on a group or individual outside of the team that has not been resolved.
• Another story the team must complete first in order to complete the blocked story.
• Lack of progress on tasks other team members must finish for a member to complete that person’s tasks within the sprint.
• Events not covered by current-sprint user stories taking time away from sprint work, including:
  • Valid reasons such as a customer emergency that could not have been predicted.
  • Inappropriate actions the Facilitator will need to address, such as a manager ordering a team member to do non-sprint work.

When a story still in the Product Backlog has a blocker, the team should take actions to remove the blocker, and review it regularly until those actions have done so. Usually it is a very bad idea to plan a blocked story into a sprint. If the blocker does not get cleared in time, the team will fail to deliver that story.

Once a sprint is under way, team members should block early and often to tackle problems while still relatively small. The longer you wait, the less time you have to resolve it and complete the remaining tasks. Blocking is done at the task level in this case under FuSca, both because it is easier to see where the problem is, and because it is possible for more than one task to be blocked, by different problems. Blocking is done by marking the task as blocked in your tracking tool or on the story card, and by announcing the blocker during the Daily Standup. A Facilitator must make any blocker their top priority once aware of it. The Facilitator might not remove the blocker personally, but making sure it has been addressed and driving a quick solution is a primary responsibility of the role.

Multiple Layers of Quality

Because Scrum drives toward delivering something to a customer every sprint (whether or not that actually happens), the team tries to get a story’s output to a level of quality it would be proud to show the customer. This is supported a number of ways. First, the team is structured cross-functionally. There are no “handoffs” from, for example, the hardware engineers to the firmware engineers, or from the software developers to the testers. The hardware, firmware, software, and test engineers responsible for that part of the product are all on the same team, working on the same set of user stories. Preferably, the line is blurred between developers and testers: Developers test each others’ work, freeing up testers to add value in other ways. These include exploratory testing—trying to break the product before the customer gets a chance—and test automation, which speeds up delivery significantly by eliminating manual work.

Other FuSca techniques to help the team build quality in from the start include:

• Setting time aside via quality-related tasks in each story to ensure the team does not scrimp on quality to meet the sprint date.
• Not “accepting” stories as completed if defects the team found were not fixed.
• Requiring teams to fix other bugs found during one sprint in the next sprint.
• Recommended use of Agile methods related to quality, such as “Acceptance Test-Driven Development,” which emphasizes writing the test first and then developing to it.

When Primavera Systems switched from waterfall to Agile, specifically the Scrum and Test-Driven Development methods, it saw “a 30 percent increase in quality as measured by the number of customer-reported defects in the first nine months following the release” and a 75% improvement in team-level defect rates.[7]

Low-Cost Release Planning

New versions of hardware and older software systems are impossible to release in a single sprint, in part because usually more than one small team is needed to develop them. Like some other Agile-at-scale systems, FuSca has proven Scrum is perfectly capable of handling multi-team, multi-sprint releases. Relative to others, FuSca makes the process as lean as possible:

1. Only the cross-team roles are involved in release planning until requirements are well-groomed, meeting weekly.
   Note: Requirements at this level are called “epics,” still written in user story format, but sized to fit within releases instead of sprints.
2. Product Owners are brought in then to:
   1. Confirm the epics are clear.
   2. Predict likely questions from the team and get them answered.
   3. Represent team wishes regarding which epics they want to work on.
3. Each team breaks its epics down into user stories.
   Note: Done as part of an otherwise normal sprint on the team’s schedule, in one workday or less, this means teams never stop productive development.
4. In a final release planning meeting:
   1. By comparing a team’s story total to its per-sprint delivery rate, the release planners and POs decide whether the team is trying to do more than it can within the release period.
      Example: If the team broke its epics into 48 stories, four sprints are left in the release, and the team reliably gets 9 stories accepted each sprint, it is over-committed by more than a sprint’s worth of stories: (9 x 4 = 36) – 48 = –12.
   2. In that case, requirements or stories get traded to less burdened teams, if possible, or requirements get removed from the release plan if not.

The combination of the planning process and jointly held demonstration ceremonies in FuSca eliminates the need for “scrum-of-scrum” meetings. This saves each participant a half-hour or more of time each week with no impact on the system’s predictability or productivity.

In cases where companies or the outputs cannot be fully tested continuously, releases are overlapped. When system validation and regression testing requires a sprint after development teams release their deliverables, for example, the teams go ahead with the next release but allow extra time for defect fixing during the sprint. Whether or not the system testers are embedded in the teams, they create stories for that testing. By overlapping release-related efforts instead of stopping for “big-room planning” or “hardening” sprints, FuSca keeps teams moving forward.

Despite this Lean approach, FuSca principles have allowed programs to hit delivery rates as high as 90% of planned epics in four-month releases.

↑ Agile 101 | ← Agile Difference | → Implications and Benefits

---

Full references are in the Agility Bibliography.

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

[2] Schwaber & Beedle 2002.

[3] You may see a cartoon in Agile sources referring to participants and observers as “pigs” and “chickens.” I avoid the terms because people from some cultures find it insulting to be called a pig.

[4] Screen shot from the tool called “Rally.”

[5] James 2016.

[6] Most Agile-at-scale systems move the “Product Owner” term up to this level. I explain the reasoning behind my approach under “Customer.”

[7] Schatz & Abdelshafi 2005.