Chapter 4

Working throughout the Day

IN THIS CHAPTER

Planning each day

Tracking daily progress

Looking at team members’ daily roles

Developing and testing every day

Ending the day

It’s Tuesday, 9 a.m. Yesterday, you completed sprint planning, and the development team started work. For the rest of the sprint, you’ll be working cyclically, where each day follows the same pattern.

In this chapter, you find out how to use agile principles daily throughout each sprint. You see the work that you will do every day as part of a scrum team: planning and coordinating your day, tracking progress, creating and verifying usable functionality, inspecting and adapting, and identifying and dealing with impediments to your work. You see how the different scrum team members work together each day during the sprint to ensure transparency as they help create the product.

Planning Your Day: The Daily Scrum

With agile product development, you make plans throughout the entire development effort — and on a daily basis. Agile development teams start each workday with a daily scrum meeting to evaluate their progress and adapt their plan for the day based on what was accomplished previously. They will identify and coordinate the resolution of impediments (roadblocks requiring scrum master involvement), note completed items, and synchronize and plan what each team member will do during the day to achieve the sprint goal.

The daily scrum is stage 5 on the Roadmap to Value. You can see how the sprint and the daily scrum fit into product development in Figure 4-1. Note how they both repeat.

© John Wiley & Sons, Inc.

FIGURE 4-1: The sprint and the daily scrum in the Roadmap to Value.

Covering important topics

In the daily scrum meeting, each development team member addresses the following four topics, which facilitate team coordination:

• What was completed yesterday to help accomplish the sprint goal?

  Avoid using the daily scrum as a status report by having each developer give an accounting of what they did the day before or by moving completed items around on the task board. Developers should update their task as soon as they complete it, or at the very least at the end of the day, so that when the scrum team comes together for their daily scrum the next day, the status is already reflected. In other words, don’t spend time on what was accomplished yesterday unless it effects how to go about the work to be done today.

• What will be done today to help accomplish the sprint goal?
• What impediments are in the way of accomplishing the sprint goal?
• This is how I feel. (The fourth topic helps the scrum master better understand team health daily rather than once per sprint.)

Other names you might hear for the daily scrum meeting are the daily huddle or the daily standup meeting. Daily scrum, daily huddle, and daily standup all refer to the same thing. Daily scrum is how scrum refers to it.

The scrum master also addresses these three statements regarding the team’s impediments:

• Impediments resolved yesterday
• Impediments that need to be resolved today (and order of priority)
• Impediments that need to be escalated

What does the product owner do during the daily scrum? Listen. The product owner listens to see whether there is anything he or she can do to help the team accomplish their work more effectively. The product owner may provide clarification as needed, and might say something if he or she hears something that indicates that the development team is working on something outside the sprint goal. An engaged, decisive product owner makes life easier for a development team.

Ensuring an effective meeting

One of the rules of scrum is that the daily scrum meeting should last 15 minutes or less. Longer meetings eat into the development team’s day. Standing encourages shorter meetings (which is why the meeting is referred to also as the daily standup). You can also use props to keep daily scrum meetings quick.

Consider starting meetings by tossing an item, such as a squeaky burger-shaped dog toy — keep it clean! — to a random development team member. Each person addresses the four topics and then passes the squeaky toy to someone else. If people are long-winded, change the prop to a 500-page ream of copy paper, which weighs about five pounds. Each person can talk for as long as he or she can hold the ream out to one side. Either meetings will quickly become shorter, or development team members will quickly build up their arm strength — it’ll probably be the former.

To keep daily scrums brief and effective, the scrum team can follow several guidelines:

• Anyone may attend a daily scrum, but only the development team, the scrum master, and the product owner may talk. The daily scrum is the scrum team’s opportunity to coordinate daily activities, not take on additional requirements or changes from stakeholders. Stakeholders can discuss questions with the scrum master or product owner afterward, but stakeholders should not distract the development team from the focus of the sprint.
• The focus is on immediate priorities. The scrum team should review only completed tasks, tasks to be done, and roadblocks.

• Daily scrum meetings are for coordination, not problem-solving. The development team and the scrum master are responsible for having relevant discussions of the tasks they’re working on and removing roadblocks during the day.

  To keep meetings from drifting into problem-solving sessions, scrum teams can

  • Create a list on a whiteboard to keep track of issues that need immediate attention, and then address those issues directly after the meeting with only those team members who need to be involved.
  • Hold a meeting, called an after-party, to solve problems after the daily scrum is finished. Some scrum teams schedule time for an after-party every day; others meet only as needed.
• The daily scrum is for peer-to-peer coordination. It is not used for an individual to report status to one person, such as the scrum master or product owner. Status is reported at the end of each day in the sprint backlog, and should take developers about one minute.
• Such a short meeting must start on time. It’s not unusual for the scrum team to have a working agreement for ensuring that meetings start and end on time. Creative punishments for tardiness include doing pushups or adding penalty money into a team celebration fund. Whatever punishment is used, the scrum team agrees on it together; the method is not dictated to them by someone outside the team, such as a manager.
• The scrum team may request that daily scrum attendees stand up — rather than sit down — during the meeting. Standing up makes people eager to finish the meeting and get on with the day’s work.

Daily scrum meetings are effective for keeping the development team focused on the right tasks for any given day. Because the development team members are accountable for their work in front of their peers, they are less likely to stray from their daily commitments. Daily scrum meetings also help ensure that the scrum master and development team can deal with roadblocks immediately. These meetings are so useful that even organizations that are not using any other agile techniques sometimes adopt daily scrums.

Think about holding daily scrum meetings 30 minutes after the development team’s normal start time to allow for traffic jams, emails, coffee, and other rituals when starting the day. Having a later daily scrum meeting also allows the development team time to review defect reports from automated testing tools that were run the night or weekend before.

The daily scrum is for discussing progress and planning each upcoming day. As you see next, you also track progress — not just discuss it — every day.

Tracking Progress

You also need to track the progress of your sprint daily. This section discusses ways to keep track of the tasks in your sprint.

Two tools for tracking progress are the sprint backlog and a task board. Both the sprint backlog and the task board enable the scrum team to show the sprint’s progress to anyone at any given time.

The Agile Manifesto values individuals and interactions over processes and tools. Make sure your tools support, rather than hinder, your scrum team. Modify or even replace tools if needed. Read more about the Agile Manifesto in Chapter 1 of Book 4.

The sprint backlog

During sprint planning, you concentrate on adding user stories and tasks to the sprint backlog. During the sprint itself, you update the sprint backlog daily, tracking progress of the development team’s tasks for each working day. Figure 4-2 shows the sprint backlog for this book’s sample application, the XYZ Bank’s mobile banking application, as it would appear after day 4 of the first sprint. (Chapter 3 in Book 4 discusses details of the sprint backlog.)

You can create a sprint backlog using a spreadsheet and charting program such as Microsoft Excel. Make the sprint backlog available to the entire team every day. That way, anyone who needs to know the sprint status can find it instantly.

Near the top left of Figure 4-2, note the sprint burndown chart, which shows the progress that the development team is making. You can see that the development team members have completed tasks close to the even burn rate of their available hours, and the product owner has accepted several user stories as complete.

You can include burndown charts on your sprint backlog and on your product backlog. (This chapter concentrates on the sprint backlog.) Figure 4-3 shows the burndown chart in detail.

© John Wiley & Sons, Inc.

FIGURE 4-2: Sample sprint backlog.

© John Wiley & Sons, Inc.

FIGURE 4-3: A burndown chart.

A burndown chart is a powerful tool for visualizing progress and the work remaining. The chart shows the following:

• The outstanding work (in hours) on the first vertical axis
• Time, in days along the horizontal axis

Some sprint burndown charts, like the one in Figure 4-3, also show the outstanding story points on a second vertical axis that is plotted against the same horizontal time axis as hours of work remaining.

A burndown chart enables anyone to see the status of the sprint at a glance. Progress is clear. By comparing the realistic number of hours available to the work remaining, you can find out daily whether the effort is going as planned, is in better shape than expected, or is in trouble. This information helps you determine whether the development team is likely to accomplish the sprint goal and helps you make informed decisions early in the sprint.

Figure 4-4 shows samples of burndown charts for sprints in different situations. Looking at these charts, you can tell how the work is progressing:

• Expected: This chart shows a normal sprint pattern. The remaining work hours rise and fall as the development team completes tasks, ferrets out details, and identifies tactical work it may not have initially considered. Although work occasionally increases, it is manageable, and the team mobilizes to complete all user stories by the end of the sprint.
• More complicated: In this sprint, the work increased beyond the point at which the development team felt it could accomplish everything. The team identified this issue early, worked with the product owner to remove some user stories, and still achieved the sprint goal. The key to scope changes within a sprint is that they are always initiated by the development team — no one else.

  

  © John Wiley & Sons, Inc.

  FIGURE 4-4: Profiles of burndown charts.

• Less complicated: In this sprint, the development team completed some critical user stories faster than anticipated and worked with the product owner to identify additional user stories it could add to the sprint.

• Not participating: A straight line in a burndown means that the team didn’t update the burndown or made zero progress that day. Either case is a red flag for future problems.

  Just like on a heartbeat graph, a horizontal straight line on a sprint burndown chart is never a good thing.

• Lying (or conforming): This burndown pattern is common for a new agile development team that might be accustomed to reporting the hours that management expects, instead of the time the work really takes, and consequently tends to adjust the team’s work estimates to the exact number of remaining hours. This pattern often reflects a fear-based environment, where the managers lead by intimidation.
• Failing fast: One of the strongest benefits of this simple visualization of progress is the immediate proof of progress or lack thereof. This pattern shows an example of a team that wasn’t participating or progressing. Halfway through the sprint, the product owner decided to cut losses by killing the sprint and starting a new sprint with a new sprint goal. Only product owners can end a sprint early.

The sprint backlog helps you track progress throughout each sprint. You can also refer to earlier sprint backlogs to compare progress from sprint to sprint. You make changes to your process in each sprint (read more about the concept of inspect and adapt in Chapter 5 of Book 4). Constantly inspect your work and adapt to make it better. Hold on to those old sprint backlogs.

Another way to keep track of your sprint is by using a task board. Read on to find out how to create and use one.

The task board

Although the sprint backlog is a great way to track and show development progress, it’s probably in an electronic format, so it might not be immediately accessible to anyone who wants to see it. Some scrum development teams use a task board along with their sprint backlog. A task board provides a quick, easy view of the items in the sprint that the development team is working on and has completed.

You can’t deny the status a task board shows. Like the product roadmap, the task board can be made up of sticky notes on a whiteboard. The task board will have at least the following four columns, from left to right:

• To Do: The user stories and tasks that remain to be accomplished are in the far left column.
• In Progress: User stories and tasks that the development team is currently working on are in the In Progress column. Only one user story should be in this column. Having more user stories in progress is an alert that development team members are not working cross-functionally and, instead, are hoarding desired tasks (not swarming). You risk having multiple user stories partially done instead of more user stories completely done by the end of the sprint.
• Accept: After the development team completes a user story, it moves it to the Accept column. User stories in the Accept column are ready for the product owner to review and either provide feedback or accept.
• Done: When the product owner has reviewed a user story and verifies that the user story is complete, the product owner can move that user story to the Done column.

Limit your work in progress! Select only one task at a time. Leave other tasks available in the To Do column. Ideally, a development team will work on only one user story at a time and swarm on the tasks of that user story to complete it quickly. High-performing teams and organizations do one item well before moving onto the next item.

Because the task board is tactile — people physically move a user story card through its completion — it can engage the development team more than an electronic document ever could. The task board encourages thought and action just by existing in the scrum team’s work area, where everyone can see the board.

Allowing only the product owner to move user stories to the Done column prevents misunderstandings about user story status.

Figure 4-5 shows a typical task board. As you can see, the task board is a strong visual representation of the work in progress.

The task board is a lot like a kanban board. Kanban is a Japanese term that means visual signal. Toyota created these boards as part of its lean manufacturing process.

In Figure 4-5, the task board shows four user stories, each separated by a horizontal line called swim lanes. The first user story is done. All tasks are completed, and the product owner has accepted the work done. For the second user story, the development work is completed but is waiting for acceptance by the product owner. The third user story is in progress, and the fourth user story has not yet been started. At a glance, the status of each user story is clear not only to the scrum team, making tactical coordination faster and easier, but also to interested stakeholders.

© John Wiley & Sons, Inc.

FIGURE 4-5: Sample task board.

Agile product development day-to-day work involves more than just planning and tracking progress. In the next section, you see what most of your day’s work will include, whether you’re a member of the development team, a product owner, or a scrum master.

The product owner owns the product backlog. The development team owns the sprint backlog. Ownership means keeping the backlog updated, clarified, and transparent.

Understanding Agile Roles in the Sprint

Each member of a scrum team has specific daily roles and responsibilities during the sprint. The day’s focus for the development team is producing valuable shippable functionality. For the product owner, the focus is on preparing the product backlog for future sprints while supporting the development team’s execution of the sprint backlog with real-time clarifications. The scrum master is the agile coach and maximizes the development team’s productivity by removing roadblocks and protecting the development team from external distractions.

Following are descriptions of the responsibilities of each member of the product team during the sprint. In the later section “Creating Shippable Functionality,” you see how the product owner and development team work together to create the product.

Keys for daily product owner success

A successful product owner focuses on ensuring that the development team has everything they need to keep the development speed (velocity) high. The product owner works to understand the problems and needs of customers by meeting with them frequently. Product owners shield the development team from competing priorities, allowing them to focus on the sprint goal. By sitting with the rest of the scrum team, the product owner can provide instant feedback as work is completed, enabling the development team to turn requirements into valuable working functionality.

The product owner has the following responsibilities during a typical day in a sprint:

• Proactive contributions:
  • Look forward to the next sprint and elaborate user stories in readiness for the next backlog refinement or sprint planning meeting.
  • Add new user stories to the product backlog as necessary and ensure that new user stories support the product vision, release goal, and sprint goal.
  • Collaborate with other product owners or stakeholders to align on release or sprint goals. Maintain the product backlog as necessary.
  • Review the product budget to stay abreast of product expenses and revenues.
  • Review product performance information and trends in the marketplace.
  • With the scrum master, watch for opportunities to proactively remove impediments that could impede development if not addressed early, such as product questions arising during sprint planning or legal wording.
• Reactive contributions:
  • Provide immediate clarification and decisions about requirements to keep the development team developing.
  • Remove business impediments brought by other members of the scrum team, such as unplanned requests from other teams or stakeholders. Shield the team from business distractions.
  • Review completed user story functionality and provide feedback to the development team.

Keys for daily development team member success

Successful development team members have pride in their work. They build high-quality, enduring products. They engineer their work for change, realizing refactoring is necessary and expected as more is learned. They sit next to their teammates and perform tasks, even unfamiliar tasks, to expand their capabilities and contributions to their team. They excel in their particular discipline and look to expand their capability each day.

If you’re a member of the development team, you

• Proactive contributions
  • Select the tasks of highest need and complete them as quickly as possible.
  • Collaborate with other development team members to design the approach to a specific user story, seek help when you need it, and provide help when another development team member needs it.
  • Collaborate with other scrum development teams to technically align on release or sprint goals.
  • Continually improve regression test automation, CI/CD pipelines, and unit testing. (CI stands for continuous integration, and CD stands for continuous deployment. Find out more in the later section “Developing.”)
  • Evaluate opportunities to improve the product architecture and development processes.
  • Alert the scrum master to any roadblocks you can’t effectively remove on your own.
• Reactive contributions
  • Request clarification from the product owner when you’re unclear about a user story.
  • Conduct peer reviews on one another’s work.
  • Take on tasks beyond your normal role as the sprint demands.
  • Fully develop functionality as agreed to in the definition of done (described in the later section “Creating Shippable Functionality”).
  • Report daily on the amount of work remaining for your tasks in the sprint backlog.

Keys for daily scrum master success

Successful scrum masters are both coaches and facilitators. They coach the team to improved performance and facilitate team interactions to help the team reach decisions quickly. They inspire, lead, challenge, and serve. Because they also sit with the team, each day they look for opportunities to serve their team members by removing impediments, by coaching the broader organization to better work with the team, and by making sure the organization’s environment enables success. After low-hanging-fruit team improvements are made, a scrum master’s job only gets harder as he or she works to remove more difficult organizational impediments affecting the team. The scrum master is the process owner in the scrum framework.

If you’re a scrum master, you do the following during a typical day:

• Proactive contributions:
  • Uphold agile values and practices by coaching the product owner, development team, and organization when necessary.
  • Remove roadblocks and organizational issues, both tactically for immediate problems and strategically for potential long-term issues. Scrum masters question the status quo of organizational constraints that strategically impede scrum teams from becoming higher functioning.

  • Build relationships to foster close cooperation with people working with the scrum team. Build clout and champion agility throughout the organization.

    Nonverbal communication says a lot. Scrum masters can benefit from understanding body language to identify unspoken tensions in the scrum team.

  • Prepare for upcoming facilitation opportunities, such as researching retrospective models to help the team maximize their retrospective discussion and acquiring supplies to facilitate affinity estimation.
  • Shield the development team from external distractions.
  • Collaborate with other scrum masters and stakeholders to resolve or escalate impediments.
• Reactive contribution:
  • Facilitate consensus building in the scrum team, as needed.

Here is some advice for scrum masters: “Never lunch alone. Always be building relationships.” You never know when you’ll need to rely on relationships to remove an obstacle.

Keys for daily stakeholder success

As members of the product team, successful stakeholders know how to work with the product owner to ensure product success. They counsel, collaborate, and listen. They give feedback and support. In flat, agile organizations, stakeholders empower, coach, and serve the scrum team rather than direct their activities from the outside or top-down. Each day, they participate in team discussions when asked but otherwise reserve their feedback for sprint review discussions.

If you’re a product stakeholder, you do the following during a typical day:

• Proactive contributions:
  • Counsel with the product owner on customer needs and backlog priorities.
  • Look for opportunities to remove team impediments. Continually ask how you can help.
• Reactive contributions:
  • Participate in sprint reviews and provide feedback. Be available to attend any other discussion requested by the team.
  • Look at team burndowns or task boards. Look for opportunities to help the team become successful.
  • Practice Principle 5, “Give the team the environment and support they need, then trust them to get the job done.” (See Chapter 1 in Book 4 for more information.)

Keys for daily agile mentor success

For teams new to agile techniques, agile mentors are critical sounding boards for the team. They challenge the team’s thinking, helping to create healthy tension. Similar to scrum masters, they coach, challenge, and serve. They teach them to find answers themselves (rather than just give them the answers). The team understands that they’ll get honesty and candor from the agile mentor. Agile mentors work to become redundant, transitioning their experience and expertise to the scrum master. Agile mentors participate daily in whatever way the team needs them.

Strategically, agile mentors engage with the organization’s leaders to help maximize the value created by the teams. The scrum team’s maximum pace is determined by the environment in which they’re working. Agile mentors help leaders improve the environment according to agile values and principles.

If you’re an agile mentor, you do the following during a typical day:

• Proactive contributions:
  • Counsel with the scrum master, primarily to help them build expertise, clout, and capability to effectively coach, trailblaze, and facilitate.
  • Provide agility mentoring to developers and the product owner in the form of in-the-moment course corrections as they strive to learn and improve their roles.
  • Coach stakeholders and other organizational leaders on how they can best support the scrum team to deliver valuable and potentially shippable functionality for the customer at every sprint.
• Reactive contributions:
  • Observe scrum team events as well as informal interactions and provide feedback and guidance.
  • Attend any discussion requested by the team.
  • Inspect team burndowns or task boards. Provide feedback on opportunities to help the team become successful.

Creating Shippable Functionality

The objective of the day-to-day work of a sprint is to create shippable functionality for the product in a form that can be delivered to a customer or user.

Within the context of a single sprint, a product increment or shippable functionality means that a work product has been developed, integrated, tested, and documented according to the definition of done and is deemed ready to release. The development team may or may not release the increment at the end of the sprint because release timing depends on the release plan. The release plan may require multiple sprints before the product contains the set of minimum marketable features necessary to justify a market release.

It helps to think about shippable functionality in terms of user stories. A user story starts out as a written requirement on a card. As the development team creates functionality, each user story becomes an action a user can take. Shippable functionality equals completed user stories.

To create shippable functionality, the development team and the product owner are involved in three major activities:

• Elaborating
• Developing
• Verifying

During the sprint, any or all of these activities can be happening at any given time. As you review them in detail, note that they don’t always occur in a linear way.

Elaborating

With agile product development, elaboration is the process of determining the details of a product feature. Whenever the development team tackles a new user story, elaboration ensures that any unanswered questions about a user story are answered so that the process of development can proceed.

The product owner works with the development team to elaborate user stories, but the development team should have the final say on design decisions. The product owner should be available for consultation if the development team needs further clarification on requirements throughout the day.

Collaborative design is a major factor for successful products. Keep in mind these agile principles from Chapter 1 in Book 4: “The best architectures, requirements, and designs emerge from self-organizing teams,” and “Business people and developers must work together daily throughout a project.” Watch out for development team members who have a tendency to try to work alone on elaborating user stories. If a member of the development team separates himself or herself from the team, perhaps part of the scrum master’s job should be coaching that person on upholding agile values and practices.

Developing

During product development, most of the activity naturally falls to the development team. The product owner continues to work with the development team on an as-needed basis to provide clarification and to approve developed functionality.

The development team should have immediate access to the product owner. Ideally, the product owner sits with the development team when he or she is not interacting with customers and stakeholders.

The scrum master should also sit with the development team. He or she focuses on protecting the development team from outside disruptions and removing impediments that the development team encounters.

To sustain agile practices during development, be sure to implement the following development practices from extreme programming:

• Pair up development team members to complete tasks. Doing so enhances the quality of the work and encourages the sharing of skills.
• Follow the development team’s agreed-upon design standards. If you can’t follow them for whatever reason, revisit these standards and improve them.
• Start development by setting up automated tests. You can find more about automated testing later in this chapter.
• Avoid coding new features that are outside the sprint goal. If new, nice-to-have features become apparent during development, add them to the product backlog.
• Integrate changes that were coded during the day, one set at a time. Test for 100 percent correctness. Integrate changes at least once a day; some teams integrate many times a day.
• Undertake code reviews to ensure that the code follows development standards. Identify areas that need revising. Add the revisions as tasks in the sprint backlog.
• Create technical documentation as you work. Don’t wait until the end of the sprint or, worse, the end of the sprint prior to a release.

Continuous integration is the term used in software development for integrating and comprehensively testing with every code build. Continuous integration helps identify problems before they become crises. Continuous integration (CI) paired with continuous deployment (CD) is known as CI/CD. Together, teams are able to release early and often. Read more about CI/CD in Chapter 3 of Book 4.

Verifying

Verifying the work done in a sprint has three parts: automated testing, peer review, and product owner review.

It is exponentially cheaper to prevent a defect than it is to rip it out of a deployed system.

Automated testing

Automated testing means using a computer program to do the majority of your testing for you. With automated testing, the development team can quickly develop and test the product, which is a big benefit for improved team agility.

Often, agile teams develop during the day, with regression test automation and security vulnerability scanning run on a nightly or weekly cycle. After the cycle completes, the team can review the defect report that the testing program generated, report on any problems during the daily scrum, and correct those issues immediately during the day.

Software automated testing can include the following:

• Unit testing: Testing source code in its smallest parts — the component level
• System testing: Testing the code with the rest of the system
• Integration testing: Verifying that new functionality created in the development environment still works when integrated with the existing functionality
• Regression testing: Testing the product increment with previous product increments to ensure that previous functionality continues to work
• Vulnerability or penetration testing: Security testing to evaluate the product’s exposure to internal and external threats.
• User acceptance testing: Validating that the new functionality satisfies the acceptance criteria
• Static testing: Verifying that the product’s code meets standards based on rules and best practices that the development team has agreed upon

Peer review and team development techniques

Peer review and pair programming are techniques teams use to build product increments. Peer review simply means that development team members review one another’s work. Pair programming means that two people work together, with one person driving (the pilot) and one observing from behind (the navigator). Both practices improve product quality, build or expand team member capability, and reduce single-point-of-failure exposure.

A newer trend gaining momentum is mob programming. Mob programming is an approach for product development in which the entire team works on the same thing, at the same time, in the same space, and at the same computer. The entire team continuously collaborates at a single computer to deliver a single work item at a time. Customers are often invited to participate with the team as well. Mob programming extends the benefits of pair programming from two people to the entire team.

Benefits of mob programming include a broader technical understanding of the product, a faster resolution of communication and decision-making problems, preventing the need to do more than is barely sufficient, reduced technical debt, reduced thrashing of the team and team members, and reduced work in progress.

However the team chooses to review each other’s work, collocation helps make the review easy and informal — you can turn to the person next to you and ask him or her to take a quick look at what you just completed. Self-managing teams should decide what works best for them.

Product owner review

When a user story has been developed and tested, the development team moves the stories to the Accept column on the task board discussed earlier in this chapter. The product owner then reviews the functionality and verifies that it meets the goals of the user story, per the user story’s acceptance criteria. The product owner verifies (accepts or rejects) user stories throughout each day as the development team completes them.

As discussed in Chapter 3 of Book 4, the back side of each user story card has verification steps. These steps allow the product owner to review and confirm that the code works and supports the user story. Figure 4-6 shows a sample user story card’s verification steps.

© John Wiley & Sons, Inc.

FIGURE 4-6: User story verification.

Finally, the product owner should run through some checks to verify that the user story in question meets the definition of done. When a user story meets its acceptance criteria as well as the definition of done, the product owner updates the task board by moving the user story from the Accept column to the Done column.

While the product owner and the development team are working together to create shippable functionality for the product, the scrum master helps the scrum team to identify and clear roadblocks that appear along the way, as you find out in the next section.

Identifying roadblocks

A major part of the scrum master’s role is managing and helping resolve roadblocks that the scrum team identifies. Roadblocks are anything that thwarts a team member from working to full capacity.

Although the daily scrum is a good place for the development team to identify roadblocks, the development team may come to the scrum master with issues anytime throughout the day.

Examples of roadblocks include the following:

• Local, tactical issues, such as
  • A manager trying to pull away a team member to work on a “priority” sales report.
  • The development team needing additional hardware, software, or access to facilitate progress.
  • A development team member who doesn’t understand a user story and says the product owner isn’t available to help.
• Organizational impediments, such as
  • An overall resistance to agile techniques, especially when the company established and maintained prior processes at significant cost.
  • Managers who might not be in touch with the work on the ground. Technologies, development practices, and project management practices are always progressing.
  • External departments that may not be familiar with scrum needs and the pace of development when using agile techniques.
  • An organization that enforces policies that don’t make sense for agile teams. Centralized tools, budget restrictions, and standardized processes that don’t align with agile processes can all cause issues for agile teams.

The most important trait a scrum master can have is organizational clout or influence. Organizational clout gives the scrum master the ability to have difficult conversations and make the small and large changes necessary for the scrum team to be successful.

Beyond the primary focus of creating shippable functionality, other things happen during the day. Many of these tasks fall to the scrum master. Table 4-1 shows potential roadblocks and the action that the scrum master can take to remove the impediments.

TABLE 4-1 Common Roadblocks and Solutions

Roadblock	Action
The development team needs simulation software for a range of mobile devices so that it can test the user interface and functionality.	Do some research to estimate the cost of the software, prepare a summary with the product owner, and have a discussion about funding. Process the purchase through procurement, and deliver the software to the development team.
Management wants to borrow a development team member to write a couple of reports. All your development team members are fully occupied.	Tell the requesting manager that the person is not available and probably will not be for the duration of the sprint. Recommend that the requester discuss the need with the product owner so he or she can prioritize it against the rest of the product backlog. As you’re likely a problem solver, you may want to suggest alternative ways in which the manager could get what he or she needs.
A development team member can’t move forward on a user story because he or she does not fully understand the story. The product owner is out of the office for the day on a personal emergency.	Work with the development team member to determine whether any work can happen around this user story while waiting for an answer. Help locate another person (stakeholder, customer, or subject matter expert) who could answer the question. Failing that, ask the development team to review upcoming tasks (not related to this stopped one) and move things around to keep progressing.
A user story has grown in complexity and now appears to be too large for the sprint length.	Have the development team work with the product owner to break the decompose user story down so that some demonstrable value can be completed in the current sprint and the rest can be put back into the product backlog. The goal is to ensure that the sprint ends with completed user stories, even smaller ones, rather than incomplete user stories.

Implementing Information Radiators

Each day, the team uses information radiators to broadcast important information to not only themselves but also to stakeholders. An information radiator is a poster, task board, list, or any artifact that can be viewed on-demand. Information radiators such as a sprint backlog or a task board reduce questions such as “What’s the status of a story?” or “Is the team on track to meet the sprint goal?” Most information radiators are posted in the team’s physical workspace or, if the team is collaborating with other teams, in a common collaboration or meeting area. If teams are using digital collaboration tools, these information radiators are clearly made transparent through obvious links and easy access.

Low-fidelity tactile information radiators are in your face and can’t be ignored, even unintentionally. They are referenced more frequently than digital tools, which you have to click or search to find. One way that a scrum master creates an environment for team success is by ensuring transparency of useful artifacts through information radiators.

Information radiators that teams find helpful include the following:

• Product vision statement and product roadmap: Provides constant visibility and clarity on the strategic product direction. See Chapter 2 in Book 4.
• Product canvas: Visualizes personas, needs, objectives, and other considerations established at the beginning of product development, and can be updated as the scrum team learns more about the customer and marketplace.
• Product backlog: Helps scrum team members and stakeholders visualize product capability and what priorities are coming up next. See Chapter 2 in Book 4.
• Sprint backlog: Displays the scope of the sprint and the status of each task.
• Task board: Displays the status of each user story in the sprint. See an example of a task board earlier in this chapter.
• Team working agreement: Reminds the team of the behaviors they agree to uphold as they work together. The agreement can be updated during sprint retrospectives and other team discussions.
• Release and sprint burndown charts with goals: Visualizes daily the progress and trends of each iteration towards goals. See Chapter 3 in Book 4.
• Definition of done: Reminds the team what shippability means and the work each user story requires. Updated during retrospectives and as the team’s abilities evolve. See Chapters 1, 3, and 5 in Book 4.
• Personas: Reminds the team through visualization of who their customers are as the team performs their work.
• Agile Manifesto, Agile Principles, and scrum values: Reminds the team of the guiding values and principles they are trying to enable, and are referred to frequently by scrum masters and agile mentors as they coach the team throughout the day. See Chapter 1 in Book 4.

Wrapping Up at the End of the Day

At the end of each day, the development team reports on the progress of tasks by updating the sprint backlog with which tasks were completed and how much work, in hours, remains to be done on new tasks started. Depending on the tool that the scrum team uses for tracking progress, the sprint backlog data may automatically update the sprint burndown chart as well.

Update the sprint backlog with the amount of work remaining — not the amount of time already spent — on open tasks. The important point is how much time and effort remains, which informs the team as to whether the scrum team is on track to meet its sprint goal. If possible, avoid spending time tracking how many hours were spent working on tasks, which is less necessary with self-correcting agile models. Also, it should take a development team less than one minute to update enterprise status reporting. If it’s taking longer than that, you have the wrong tool.

The product owner should also update the task board at least at the end of the day, and move any user stories that have passed review to the Done column.

The scrum master should review the sprint backlog or task board for any risks or impediments before the next day’s daily scrum.

The scrum team follows this daily cycle until the end of the sprint, when it will be time to step back, inspect, and adapt at the sprint review and the sprint retrospective meetings.