Contents
Choose a Tracker
What to Consider
Obviously, when Kanban and Scrum started, there were no software programs for running them! The name “Kanban” actually comes from the Japanese word for the paper cards it used. It is still fully possible for collocated teams to plan and track agile work using paper in racks or 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 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 Facilitator 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
The Paper Option
Here is what a storyboard on a wall might look like during a Scrum 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 the tasks are done. The smaller squares are the tasks needed to accomplish each story. After Grooming, these small sticky notes are 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
The Digital Option
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!
I see no reason to drag out the decision-making, though. Have a couple of people download a few trials 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 agile process 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. In my experience those are:
- Adding Stories:
- Creating a story: Create a new story without a lot of mouse or keyboard actions
- Splits: Create a new story by copying an existing story and choosing which tasks to move to the new one
- Managing a Backlog:
- Selecting order: Change a story’s rank by selecting a position number for it in a menu
- Multi-story edits: Make the same change to a specific field in multiple stories
- Multiple edits: Edit different fields in various stories in the list, and then save them all at once
- Filtering: Limit the stories shown according to specific values of various fields
- Releases:
- Release backlog: Assign stories into releases
- Release page: View which stories are in a release on a page
- Release reporting: Use a customizable Release Burndown Chart
- Reports: Customize reports easily without knowing a query language
- Task Grooming:
- Creating: Create a new task without a lot of mouse or keyboard actions
- Copying: Copy tasks between stories (without copying the story)
- Drag-and-drop: Re-rank a task by dragging it to a new position
- Multi-task edits: Make the same change to a specific field in multiple tasks
- Multiple edits: Edit different fields in various tasks in the list, and then save them all at once
- Sprint Planning:
- Adding stories: Drag-and-drop stories from a backlog into a sprint
- Capacity: Enter member capacities (hours available for sprint work)
- Hour commitments: Easily see that a member’s task estimates are over their capacity
- Testing (Ignore if using another tool):
- Test cases: Associate a test case with a defect
- Storage: Store test cases for re-use in other stories
- Rates: Report defects per time period
- Escapes: In reports, separate stand-alone defects from those assigned to a story
- Integrations with Other Systems: Automated updating between the tool and related ones like sales, customer service or testing applications
As a sign of 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 Agile, 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 met 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 locally, 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 agile. 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.
⇒ Steps: Prepare the Digital Tracker for Trial
Identify Guidance Roles
The Roles of Full Scale agile
With the tool decision made or under way, identify who will fill three standard FuSca™ team-level roles. The Team Guide (TG) is the person who serves as the point of contact for the customer and communicates the direction and scope for the team. The Facilitator runs all meetings and serves as a coach helping the team stick to its processes. (In classic Scrum these are called the “Product Owner” and “Scrum Master,” respectively.) 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.[1] Hence I refer to these as the “Guidance Roles,” meaning people providing services to the teams, not commands.
In FuSca, 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 pages.
Customer
Although not considered a formal role in traditional Scrum or Kanban, 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 Team Guide 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 TG.
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 business analyst. 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 TG to create, review, and rank-order user stories in the Backlog.
- Attend every Demonstration Ceremony.
- Review story deliverables and accept or reject them.
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 TG 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 TG or Facilitator unless needing more details.
- Respond to team member questions about in-progress stories 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 Team Guide. In the worst case, the TG becomes the de facto Customer. In this situation, the TG 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/TG with deep knowledge of the team and familiarity with its technology. When the team doesn’t have its own PO/TG, also, the role’s team-level tasks usually devolve to the Facilitator, raising the likelihood of that person becoming a “team leader” in effect if not name. That said, if you want to call this role “Product Owner” and still have team-level TGs, that’s fine.
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” for an end consumer of your goods or services.
⇒ Steps: Identify Customer
Team Guide
The Team Guide 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 TG will not take up the majority of the person’s working time once FuSca is running smoothly. The TG 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 TG 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 non-emergency work, and help determine how to accommodate emergencies within a sprint if using Scrum.
- For Scrum teams:
- Attend all sprint meetings (“ceremonies”) and Grooming Sessions.
- Represent the team in Release Planning, if used.
The rest of the time the TG takes on regular work tasks like any other team member.
Facilitator
Once a Scrum team is up and running, the Facilitator 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 Facilitator:
- 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 backup defender of team processes from interference by customers, managers, or others in the company (in support of the affected team member[s]).
- Serves as a backup for the Team Guide.
Putting Names to Roles
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. The manager cannot serve in the Customer role. This would make it impossible for the team to exercise independent thinking.
The team, being self-organizing, must select its Team Guide and Facilitators. 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 TG 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.
However, 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.
If all members are willing to rotate the role, they 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 volunteers 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! Eventually a second, also newer, member agreed as well.
Another option is transitioning from within (or hiring) someone to be a full-time Facilitator 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 Facilitator 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 Facilitator 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 TG role, especially if you do not have an external customer. The TGs 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 TG 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 TG and Facilitator serve as a check-and-balance, reminding each other of the responsibilities and limitations of each role. If the TG starts acting like a boss, the Facilitator can rein them 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.
Choose a Sprint Cycle
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 that people consistently underestimate how long something will take, recognized by psychologists as a “cognitive bias” most people have.
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.”[2]
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, using the exact same schedule increases the odds of schedule conflicts and burnout. Note, however, that teams in the same program using FuSca 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.
⇒ Steps: Identify TG, Facilitators, and Sprint Length
↑ The Sprint Process | ← Points to Remember | → Get Organized
[1] See “Re-focusing on Team Performance” for Agile ways of performance evaluation.
[2] Maccherone, L. (2014), “The Impact of Agile Quantified,” Agile 2014 conference presentation slides: Orlando, FL.