Scrum/Guide

These notes provide additional thoughts on Scrum Master in Under 10 Minutes, an instructional video which provides a surprisingly good overview of the methodology despite a 90s-era techno soundtrack. Topics are discussed in the order that they are presented in the video.

Product Backlog

• The video does a good job of describing this
• The product backlog is a wishlist
• The product backlog is collaborative. Executives, developers, testers, etc. can all contribute to it.
  • Either by writing backlog items, or by influencing the product owner to write backlog items

Roles

• The video also does a good job of describing the role of the product owner
  • The product owner is the filter of all the ideas that are presented
  • The product owner does set direction
• In some teams, the Scrum master should do little else than coordinate efforts and ensure that the software is high-quality and progressing well
• It is sometimes useful to create subteams within large development groups. In such a setup, high-level requirements might be communicated to a team lead ("Users must be able to visit the site homepage"), with lower-level requirements communicated by the team lead to individual developers ("Users must be able to identify the site by reading the header", "Users must be able to get more information by reading the footer", etc.).

Responsibilities

In general, teams tend to be organized such that each role has the following responsibilities.

• Everyone
  • Post ideas (in the form of stories) to the product backlog. "We need to make sure contributors can't post insecure code to the wiki. I'll add a story for that." It is the job of the product owner to act as the filter of all stories that are added.
• The Team
  • At each planning meeting, estimate the story points of upcoming stories in the product backlog.
  • At each planning meeting, build a sprint backlog based on the priority and complexity (story points) of items in the product backlog.
  • Self-select stories to work on during each sprint. "I'd really like to work on this story, because I've done a lot of work with this kind of stuff in the past."
  • Develop the software and reach out to the Scrum master when blocked.
• Product Owner
  • Represent the customers. Act as their voice. "Administrators really need this feature to be added."
  • Own the product backlog. Prioritize the backlog, add and remove stories as necessary, and act as the filter of all stories that are added.
  • Approve sprint backlogs created by the team.
• Scrum Master
  • Ensure Scrum is being used properly within the project. Answer questions, make recommendations, and coordinate tradeoffs when necessary.
  • Organize all meetings.
  • Coordinate the work of developers by ensuring that the right people are talking to each other, by ensuring that the work comes together well, etc.
  • Ensure that all developers are able to contribute what they are best at, without micro-managing them or deciding how they should do their work.
  • Ensure each release adheres to the agreed-upon definition of "done".

Release Backlog

• The concept of a release backlog is rarely mentioned in Scrum literature
• Mike Cohn (one of the top names in Scrum) makes a convincing argument against it in his article Why There Should Not Be a "Release Backlog"
  • Basically, a release backlog is an unnecessary additional layer
  • Nothing can be promised many months in advance
  • Things change!
  • Instead, Cohn suggests Scrum teams take a different perspective
    • Work as normally
    • Use Scrum data (e.g., the burndown chart) to estimate the team's development velocity
    • Use this velocity to estimate the number of tasks that can be completed by the deadline
• For this video, it is safe to mentally replace the term "release backlog" with "product backlog"

Estimating

• Subject experts are indeed very useful in forming accurate estimates
• Teams that have trouble with estimating can use a simple but very useful technique called Planning Poker to improve their accuracy
• It is often better to do a few things well than to do a lot of things badly
• Be realistic. No one can work until 4am.
  • The story of the Chicken and the Pig
    • A chicken (manager) and a pig (developer) decide to open a restaurant
    • Chicken: "Let's call it 'Bacon and Eggs'"
    • Pig: "You would be involved, but I would be committed."
  • This is sort of a silly metaphor, but it makes an important point. Part of the purpose of using Scrum is protecting the developers.
  • To some degree, developers need a tool that allows them to say "No." to a 2am, day-before-the-deadline feature request.

Sprints

• The video is correct that a late Sprint suggests a late product
• Every Sprint should create a "ship-ready" product, a "complete slice"
  • This should be something that the team can fall back on. The team should feel confident in saying, "Funding dried up, but at least the last release does XYZ and does it completely."
  • The product created by a Sprint will not do everything, but it should provide a complete user experience
    • For example, imagine a product that allows users to share media. At the end of one Sprint, photo support is completed but video support is not. The sortware released at the end of this Sprint should allow the user to create an account, log in, and click "Post a photo" to post a photo. No link for posting videos should be provided, because in this imagined situation video upload is not completed yet.
    • It would make little sense to build, say, photo upload support before building user login. That would create an incomplete user experience.

Burndown Chart

• A burndown chart can be useful, but without the right tools it can require too much overhead. See the Tools page.

Defect Backlog

• Like the release backlog, the defect backlog is rarely mentioned in literature
• Some teams mix bugs with user stories and other tasks in the product backlog

Daily Standup Meeting

• This meeting is more important than the video argues
  • Constant feedback loop. "Jimmy isn't finishing enough work, but Jimmy is always confused by the system architecture."
• Doing this over email or wiki often requires too much overhead
• Some teams, such as Development Seed, have had success with holding these meetings in IRC
• Some recommend holding these meetings with video chat software, but the (inevitable) technical issues could create too much overhead
• The "Standup" in "Standup Meeting" is actually very important
  • Physical constraint to limit length of meeting
  • "My back hurts. Let's not drag this thing on."

Meetings

• The video doesn't do much to discuss meetings
• Sprint planning meetings are essential
  • Small "breakout groups" are often necessary, as not everything can be decided among one, big group
  • In Sprint planning meetings, the product that will be completed at the Sprint should be carefully designed. For example, the resulting product should not be just "a thing that does voting" and "a thing that does log-in" and "a thing that does photo upload". Instead, the final product should be something like "A system that allows the user to log in, post photos, view content, and vote on the content that exists."
    • Note that in this example, the detailed product design required the explanation that viewing content is important, which was not an area covered by the individual tasks
• Sprint retrospective meetings are very important, but often overlooked. An open, honest feedback loop is more important than it seems.

Definition of Done

• Scrum requires that every feature assigned in a Sprint be completely "done" by the end of that Sprint. Different teams have different definitions of "done".
• Some teams: "The OCD Definition"
  • "Every task that we sign up for must be done perfectly. If we take on login in Sprint 1, we shouldn't have to touch login again until the software is due."
  • Not sustainable
  • Things change
  • If 12:00am Monday is the last chance to write login instructions, developers will stay up all weekend getting them just right
  • Developers will burn out. Developers will go crazy. Don't do it.
• Other teams: "The Hippy Definition"
  • "The deadline is in our minds."
  • "We'll do what we can."
  • If work can't be completed by it's original Sprint deadline, it is moved to a later date without much explanation
  • Some Sprints contain half-done features
• A good balance
  • Features must be done (and well-done)
  • Features must polished
  • Features must tested
  • Features must contribute to a complete user experience
  • No half-done work. If Sprints contain half-done work, the team will have nothing to fall back on.

Tools

See the Tools page for a survey of popular Scrum tools and project management platforms.