Scrum Framework, or how do you do Scrum?

Last post I wrote, “Scrum is a simple, team-based framework for solving complex problems.” How does the Scrum framework actually work?

Scrum is modelled on successful patterns for product development. The classic phase-driven approach, or “relay-race model” was found to be less effective than the team-oriented, “rugby model”, in which an interdisciplinary team solves the whole problem together, without explicit phases or formal leadership roles. (See “The New, New Product Development Game” at HBR for the research which inspired Scrum).

The Scrum Framework

The Scrum Framework ensures the core principle of Inspect and Adapt can take place at regular intervals. To achieve this, Scrum introduces a few constraints on the development process:

1. Time-boxing triggers inspect-and-adapt cycles. So a Sprint is time-boxed to four weeks or less.
2. An interdisciplinary Development Team solves the problem. Outsiders do not tell the Team how to organize or do its work.
3. Work taken on at the beginning of the Sprint must be finished by the end of the Sprint. So the team only takes on what it reasonably believes it can finish on time.
4. No changes to the assignment before the end of sprint. Work that is started but not finished is waste, so this should be avoided.

If you accept and believe in Scrum’s principles and constraints, then doing Scrum will come naturally to you.

Roles

“The Scrum Team” refers to an interdisciplinary, self-organizing group of people, who collaborate to define and solve the problem as effectively as possible. Within the Scrum Team, Scrum defines three roles:

• Product Owner – represents the voice of the customer or stakeholder. The Product Owner is responsible for answering the question “Why?” S/he is empowered to cancel a feature or even the development of the product if the answer is not satisfactory. The Product Owner guides development from the first formulation of the Vision to the (final) release of the product. 
• Development Team – solves the problem presented by the Product Owner. The Dev Team has all the skills need to bring an idea to the completion. It is responsible for answering the question “How?” and for creating something potentially valuable to the customer or user at least by the end of each sprint. 
• Scrum Master – represents the voice of common sense and is responsible for the process. The Scrum Master acts as trainer and coach to help the Development Team, Product Owner and indeed, the rest of the organisation, become more effective. The Scrum Master recognizes all kinds of impediments and works to eliminate or at least mitigate them.

Activities

Scrum is an iterative, incremental approach to development. So development is broken into a large number of fixed-length “sprints”, each of which produces an increment of “potentially shippable” customer visible value, which is integrated with the previously created increment to create a seamless whole.

• Sprint — the basic feedback cycle Scrum. The Development Team takes on a problem to solve at the beginning of the Sprint and commits to do its best to complete that mandate by the end of the Sprint. A Sprint should strive to achieve a clear business goal, which should be between one and three Sprints in the future.
• Sprint Planning 1 — The Scrum Team collaborates to decide what problem(s) should be solved in the current sprint. This should represent the best step forward toward the ultimate goal, given the Scrum Teams knowledge at the time of the planning.
• Sprint Planning 2 — The Development team collaborates to decide how to solve the problem they took on in Sprint Planning 1. The result is usually a technical concept and task planning. Neither needs to be definitive, but should be enough that the development team can start work.
• Daily Scrum — The Development Team inspects and adapts its own work on a daily basis. The team report to each other: What have I accomplished? What is my goal for today? What is slowing me down? Brief, clarifying questions are allowed, but longer discussion must be postponed to (immediately) after the Daily Scrum.
• Sprint Review — The Scrum Team inspects the product it created in this sprint so it can better decide how (or even whether) to move forward in the next sprint. A potentially shippable Product Increment should be available at the review, consisting exclusively of “done” functionality.
• Sprint Retrospective — The Scrum Team inspects and adapts itself, so it can be more effective in the future.
• Backlog Refinement — This is the process of keeping the backlog up to date and preparing the backlog entries for implementation. This includes ensuring that the Team understands upcoming backlog entries; estimation; “slicing” this stories into small enough pieces; and discarding or de-prioritising unneeded entries.

All activities in Scrum are time-boxed.

The sprint length must always be the same, and should be short compared to the length of the project. Two weeks is common in software development. The maximum length may be limited by the Product Owner’s ability to hold his/her word not to change the mandate: fast moving businesses generally require shorter Sprints. Four weeks is the maximum allowed by Scrum, because longer sprints have been shown to lower performance.

The Daily Scrum is time-boxed to 15 minutes. This discourages excessive talk and teams from getting too big. The remaining mandatory meetings are time-boxed to 1 hour per week of Sprint (e.g. 2 hours for a 2 week sprint, 4 hours for a 4 week sprint).

Note: the authoritative literature often combines the time-boxes for Sprint Planning 1 and 2 into one time-box of two hours per week of Sprint. I have found that the time-boxes for Sprint Planning 1 and the Sprint Review are critical. If you cannot finish Sprint Planning 1 in the allotted time, you need to invest more effort in Backlog Refinement. If you cannot finish the Sprint Review in the allotted time, your Team is probably finishing most backlog items at the last minute, and/or the items are not really Done.  

Artifacts

I don’t like the term ‘Artifact’ very much. To me, this implies objects that were created by people who died thousands of years ago and were dug up by archaeologists.  The so-called artifacts in Scrum are living entities to guide and direct the project.

Scrum defines three artifacts: the Product Backlog, the Sprint Backlog, and the Product Increment:

• Product Backlog — this is the single list of ideas for the product under construction. The Product Backlog consists of entries which represent some value to the customer or user. Each entry is:
• Sequenced – a strong form of prioritization in which each backlog item has a unique sequence number: 1, 2, 3, 4…. Sequencing is most important for the items at the top of backlog, which may be implemented in the next 2 or 3 Sprints.
• Estimated – not all Scrum Teams estimate, but if you do estimate, the Development Team does the estimating.
• Emergent – the product backlog is not a binding definition of the product, just the current best understanding of what the product should be.
• Sprint Backlog — the Team’s detailed plan on how to solve the problem. It consists of the selected backlog items from the Sprint Planning, a solution concept (how to solve the problem) and a task planning (the steps needed to complete the work involved). The task planning is often represented on a task board.
• Product Increment — Scrum achieves results incrementally, that is one slice at a time. Each backlog item defines a slice. At least once per Sprint, but possibly more often, the team must integrate all the slices of the current sprint into the previous Increment to create a new Increment. This increment and each slice in the increment must be “done” according to the Definition of Done. Should the Product Owner wish to release the Increment, there should be no impediments to doing so.

Agreements

Core Scrum introduced the notion that the Definition of Done is an Agreement, not an Artifact. At first I found this a bit strange, because the DoD was usually posted on our Wiki somewhere. But now I find the notion quite powerful, and believe that Agreements are the basis for many context specific enhancements to Scrum.

Planning in Scrum is commitment based. There is no hierarchical command authority in Scrum. Scrum defines explicitly one agreement, the Definition of Done implies a second agreement, which I call the Sprint Contract, which govern the expectations during a Sprint.

• Definition of Done. The constraint that a feature be done before it can be included in the Increment and that the Increment be potentially shippable requires that everybody mean the same thing when they call something “Done.” Generally, the Definition of Done ensures that the Team has built the right thing, that they have built in right, and if something was Done in a previous Sprint stays Done in this Sprint.

The Sprint Contract is implied by Scrum, but not explicitly named. I have found it useful to give it a name, discuss its conditions, and secure agreement among the concerned parties.

• Sprint Contract — An agreement between Product Owner and Development Team covering the current Sprint: scope (forecast), quality (Definition of Done), cost (Effort), and time (Sprint Length). The team commits to do its best to achieve the forecast. Product Owner and Development Team commit to support each other during the Sprint. Time, cost and quality remain fixed, so if the team overestimates its capacity, it will deliver less functionality than forecast. When that is the case, it should leave low-priority stories unstarted. To prevent wasted effort and unfinished work, the Sprint Contact cannot be changed unilaterally (though it can be cancelled in an emergency). The entire Scrum Team and the rest of the organisation must respect the Sprint Contract.

The following is not defined in the authoritative Scrum literature but I have found additional agreements useful in many contexts:

• Team Working Agreement — An agreement among the (Development) Team members to enable them to work together more effectively. This often covers core hours, punctuality at meetings, whether reading email is allowed during a meeting, when to update the task board, and anything else the team finds useful. 
• Additional agreements — As development teams work with their Product Owners they learn to work together effectively. This know-how is reflected in the agreements. One such agreement is the “Definition of Ready” when is a backlog item ready for execution. How often does the Scrum Team get together to do Backlog Refinement?