Introduction

SCRUMMF is a specific implementation of the Scrum agile framework, and as such, is flavored differently from vanilla. It is a view of how Scrum should be applied in our particular circumstances. Nevertheless, it is based on the official Scrum Guide, respecting the Agile Manifesto and the 12 pillars of Agile development.

The individual spices used to create the Moravia Flavor (MF) are marked with an “*”. Some of those extend and some subdue the original flavor, while keeping the core "as Scrum as possible." The original vanilla flavor is described in The Scrum GuideTM from November 2017.

Our ScrumOne variation of SCRUMMF supports a variety of planning strategies, allowing the implementing team to decide which ones to use. This reflects the fact that it is a particular implementation for particular circumstances. While trying to keep it as generic as possible to accommodate the needs of multiple teams at RWS Moravia, it is more specific than the general framework.

The major differences in nomenclature from the original are due to the historic use of Targetprocess as the main project management tool. We are using “User Stories” as a synonym for Product Backlog Items, as these are the items where we capture the business requirements in Targetprocess. Also, in this version, the term “Developers” is used instead of “Development team” to further emphasize the idea that there is only one team in Scrum: the whole Scrum Team.

ScrumOne

During implementation research for SCRUMMF, it became clear that some teams need to handle requests with a desired lead time shorter than what is provided by the two-week Scrum Sprints (where the lead time can be up to 4 weeks in worst-case scenarios). Kanban was proposed as an obvious solution, but after some research, we discovered that its practical implementation, when done properly, is comparably more difficult than the implementation of Scrum.

The idea that Scrum is the ideal application of Kanban in software development was presented by Jakub Kminek, so the decision was made to create a process that would optionally allow the requirement flexibility of Kanban while still remaining Scrum at its core to keep it readable for other teams. Since it does not include some of the major ideas from Kanban, and is thus not an enhancement of Scrum with Kanban, we have not adopted the typically used name Scrumban. Instead, as it is a specifically adjusted Scrum and should represent the idea of one shared process for all, it was named ScrumOne.

What is Scrum?

Scrum is an empirical framework for the delivery of products of the highest possible value.

Scrum is based on transparency, inspection and adaptation.

Team and Roles

Team

The Scrum Team consists of the Product Owner, Scrum Master and Developers*. Functions and responsibilities of the individual roles are listed below with specifics captured in the ToDo section of each Scrum event.

Scrum Teams are expected to be self-organizing and cross-functional.

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

The minimum amount of Developers in the Scrum Team for ScrumOne is 3 people. Every team practicing code reviews (that require at least 2 Developers) and QA is ScrumOne ready.

The optimal number of Developers on a Scrum Team is 5 people.

The maximum amount of Developers should not exceed 9 people (12 people are supported but strongly discouraged). More than 9 Developers on a team considerably increases the complexity of coordination in an empirical framework, making it lose its usefulness.

Product Owner

The Product Owner is responsible for maximizing the value of work performed by the Developers. The Product Owner is solely responsible for the management of the Product Backlog. Product Owner responsibilities include:

More detailed responsibilities are included in the ToDo section of each event.

The Product Owner can delegate the work to Developers, but remains accountable. The Product Owner must be one person, not a committee. The Product Owner can represent the interests of a committee, but that committee must always address the Product Owner.

Product Owner decisions must be respected by the whole organization for the Product Owner to succeed.

Scrum Master

The Scrum Master is responsible for the application of the ScrumOne framework by helping everyone understand its theory, practices, rules and values. The Scrum Master helps everyone optimize their interactions with the Scrum Team to maximize the value created. The Scrum Master’s main goal is to help everyone achieve the best results possible. Scrum Master responsibilities include:

To the Product Owner:

To Developers:

To the organization:

More detailed responsibilities are included in the ToDo section of each event.

Developers

Developers are professionals who do the work of delivering a potentially releasable Product Increment at the end of each Sprint. Developers are structured and empowered by the organization to organize and manage their own work. Developer responsibilities in ScrumOne include:

More detailed responsibilities are included in the ToDo section of each event.

Definition of Done

Definition of Done (DOD) ensures that those performing the work and those inspecting the results share a common understanding of what DONE means.

The minimum DOD is defined by the development organization. Individual teams can have a more detailed and stringent DOD than what is defined by the development organization. DOD for the project is defined through mutual agreement between the Developers and the Product Owner.*

The minimum definition of DOD in ScrumOne is:*

Definition of Ready

Definition of Ready (DOR) is a working agreement between the Developers and the Product Owner on what criteria a User Story must meet to be accepted into the Sprint Backlog. User Stories should be clear, concise and actionable. User Stories that meet the DOR criteria are deemed Ready. User Stories that don’t meet the DOR criteria are Not Ready.

The minimum definition of DOR in ScrumOne is:*

Product Backlog Building

The Product Backlog building event is organized by the Product Owner before development begins. The Product Owner invites the Stakeholders to this event to create a Product Backlog that is ordered by the value of each item on the list. This event is outside the scope of the ScrumOne framework, but it is mentioned here to provide the identifiable source of the Product Backlog.

Sprint

Sprints have consistent 2-week durations for frequent inspection and adaptation. A new Sprint starts immediately after the end of the previous Sprint.

Sprint Cycle Overview

Sprint Planning

Agenda

  • Review User Stories from the Product Backlog and clarify where needed.
  • Commit to completion of selected User Stories in the Sprint through acceptance by initial Developers.*
  • Break down User Stories into Tasks by respective initial Developers.
  • Decide how to build selected User Stories into a “Done” Product Increment during the Sprint.
  • Set up the Sprint Goal (a simple sentence used by the Product Owner to inform Stakeholders of the goal of the upcoming Sprint).*
  • Refine User Stories in the Product Backlog if needed.

ToDo

Product Owner

  • Cooperate with Developers and the Scrum Master on User Stories clarification.
  • Answer questions from the Developers.
  • Set up the Sprint Goal.*
  • Fine-tune the Product Backlog.

Scrum Master

  • Check Product Backlog readiness before the event.
  • Ensure that the event takes place.
  • Ensure that attendees understand the purpose of the event.
  • Capture availability and capacity information for the Sprint from the Scrum Team.
  • Cooperate with the Product Owner and Developers on User Stories clarification.
  • Conduct the Planning Poker if necessary.
  • Ensure that User Stories that are not Ready do not enter the Sprint Backlog.
  • Help set up the Sprint Plan.
  • Help set up the Sprint Goal.
  • Keep the event within its time-box (preferably shorter).

Developers

  • Cooperate with the Product Owner and Scrum Master on User Stories review and clarification.
  • Select User Stories for the next Sprint from the Product Backlog and commit to their completion.
  • Break down your assigned User Stories into Tasks.
  • Estimate your Tasks.
  • Help set up the Sprint Goal.
  • Help refine the User Stories if needed.

Rules

  • The Product Owner can put an upper limit on the amount of work that is planned for the Sprint. The Product Owner has to explicitly state the reasoning behind the limit and the Scrum Master will mark that Sprint as a Pull Sprint.*
  • The Product Owner, Scrum Master and Developers work together to clarify User Stories when needed.
  • The Developers and Product Owner are equally responsible for the clarification of the User Stories.*
  • If there is a change of scope of a particular User Story during the planning session and it was previously estimated, it must be re-estimated.*
  • User Story estimation is done with Planning Poker in Story Points.*
  • Estimates of User Stories are checked and re-estimated in Story Points if necessary.*
  • Developers select User Stories from the top of the Product Backlog, skipping User Stories that are Not Ready. User Stories can be otherwise skipped only with approval from the Product Owner.*
  • Developers select User Stories only from the Product Backlog and no other source.*
  • Only the Developer decides whether she/he will be assigned to a particular User Story, thus including it in the Sprint Backlog.*
  • Nobody can force the Developers to accept more work than they choose to.
  • By selecting a User Story, its Developers commit to its completion. That means that they will do everything in their power to finish the User Story in that Sprint, but is not an absolute guarantee that the User Story will be delivered.*
  • Multiple Developers can work on one User Story.*
  • Only a single Developer can work on a Task.*
  • Tasks are estimated individually in real hours to done (ETA) by the Developers who accepted the User Story into the Sprint.*
  • Tasks should ideally have a maximum size of 8 hours ETA.*
  • The Sprint Backlog belongs solely to the Developers.
  • If all User Stories deemed Ready are exhausted, the Scrum Team can run a Backlog Refinement within the Planning time-box and include newly refined User Stories into the Sprint Backlog based on their rank in the Product Backlog, starting from the top. Backlog Refinement can be stopped when there are enough User Stories that meet the Ready criteria prepared for the Sprint.
  • The Product Owner can freely refine and rearrange User Stories in the Product Backlog in reaction to gained insights.*
  • The event can last a maximum of 4 hours.

Development cycle

Agenda

  • Deliver Product Increment of potentially releasable functionality that respects the Definition of Done.

ToDo

Product Owner

  • Take care of the Product Backlog (including additions, removals, reprioritization and fine-tuning at her/his own discretion).
  • Consult with Stakeholders on future requirements.
  • Create development strategy for product delivery.
  • Cooperate with the Developers on required User Story clarification.

Scrum Master

  • Shield the team from the Product Owner or Stakeholders during development work.
  • Conduct the required Scrum events.
  • Implement improvements identified during the previous Sprint Retrospective.
  • Help resolve impediments.
  • Conduct daily Backlog Refinement until the Product Backlog contains enough User Stories that are Ready for the next two Sprints and all other User Stories in the Product Backlog are estimated by the Developers.*

Developers

  • Focus on the creation of the Product Increment.
  • Cooperate with the Product Owner and Scrum Master on required User Story clarification and refinement when needed.
  • Select additional work from the Product Backlog when all planned work is finished (or is irreversibly impeded in the Sprint).
  • Self-organize with the rest of the team.

Rules

  • The created Product Increment must be usable so that the Product Owner may choose to immediately release it. If it is not usable, it is not Done.
  • The Product Owner is not allowed to request additional Sprint Backlog changes from the Developers during the development work, nor is the Product Owner allowed to initiate direct contact with any Developer.*
  • The Product Owner can freely contact the Scrum Master.
  • The Product Owner can cancel the Sprint if the Sprint Goal or development work become obsolete.
  • Developers can freely ask the Product Owner to further clarify User Stories.
  • Developers can renegotiate the scope of the Sprint Commitment with the Product Owner as more is learned about the work, but a User Story can be removed from a Sprint only if the Product Owner agrees to have it removed.*
  • Quality goals do not decrease during the Sprint.
  • Only a Developer can add a User Story to a running Sprint.*
  • Developers can take new User Stories only from the top of the Product Backlog and only those that are Ready. If they need to skip a User Story, they must contact the Product Owner.*
  • User Stories accepted into the Sprint by Developers after its start must be refined by the whole Scrum Team and meet the DOR criteria.*
  • Developers should release an assigned User Story to another Developer if they see that they cannot efficiently develop that User Story in the Sprint.*
  • Developers should release an assigned Task to another Developer if they see that they cannot efficiently develop that Task in the Sprint.*
  • User Stories representing blocking bugs (bugs that have no workaround and block Stakeholders from work) are immediately presented to the Developers in an emergency refinement session.*
  • User Stories representing critical bugs (bugs that have a workaround that is not acceptable for a prolonged period of time by the Stakeholders) are presented to the Developers in the next Daily Scrum meeting.*
  • Standard bugs are entered at the beginning of the Product Backlog and the Product Owner is notified of their presence.*
  • Developers develop User Stories in a Sprint in the following order:*
    • Blocking bugs
    • Critical bugs
    • Planned User Stories and bugs with deadlines (in order of deadline closeness)
    • Planned User Stories and bugs
    • Unplanned User Stories and bugs
  • Developers update Task ETAs daily, and at a minimum, once shortly before the Daily Scrum.*
  • Developers update Task statuses immediately when they change
  • The Product Owner returns User Stories that failed the PO Revi into the Sprint Backlog and must provide a reason and description of why the User Story failed.*

Daily Scrum

Agenda

  • Synchronize work.
  • Plan work for the next 24 hours.
  • Communicate acute impediments and coordinate on possible solutions.
  • Inspect progress toward the Sprint Goal.
  • Developers often meet right after the Daily Scrum for detailed discussions.

ToDo

Scrum Master

  • Ensure that the Developers have the meeting.
  • Make the Sprint Burndown Chart accessible to the Developers.
  • Ensure the meeting is not disrupted by people who are not Developers.
  • Help with the organization of follow-up meetings.
  • Keep the event within its time-box (preferably shorter).

Developers

  • Update task estimates prior to attending the event.
  • Prepare answers to the 5 questions before attending the event.
  • Answer 5 questions during the event:*
    • What did you work on since the last Daily Scrum?*
    • What will you work on today?*
    • Do you see any impediments preventing you or the Developers from doing your/their work?*
    • Do you require code review?*
    • Any other development info to share with the team?*

Rules

  • The Daily Scrum is held every day of the development cycle.*
  • The Daily Scrum is held at the same time and place each day.
  • Developers conduct the event, but the Scrum Master can conduct it if necessary.*
  • Only the Developers and Scrum Master can actively participate in the meeting.
  • The event can take a maximum of 15 minutes.
  • The Daily Scrum must be as fast and short as possible.*
  • The Daily Scrum should be held shortly before or after a bigger natural work break (lunch, etc.).*
  • Only the required team members participate in the follow-up meetings.

Backlog Refinement

Agenda

  • Review User Stories from the Product Backlog.
  • Refine, clarify, add details and estimate User Stories for the next two Sprints so that they meet the standard of Ready.*
  • Clarify and estimate the rest of the Product Backlog.*
  • Order User Stories in the Product Backlog.

ToDo

Product Owner

Scrum Master

  • Ensure that the event takes place.
  • Ensure that attendees understand the purpose of the event.
  • Cooperate with the Product Owner and Developers on User Stories clarification.
  • Conduct the Planning Poker.
  • Keep the event within its time-box (preferably shorter).*

Developers

Rules

  • The Product Owner, Scrum Master and Developers work together to clarify User Stories.
  • The Product Owner can freely rearrange and refine User Stories in the Product Backlog in reaction to gained insights.
  • The Developers and Product Owner are equally responsible for the clarification of User Stories.*
  • If there is a change of scope of a particular User Story during the refinement session and it was previously estimated, it must be re-estimated.*
  • User Story estimation is done with Planning Poker in Story Points.*
  • Estimates are checked and re-estimated if necessary.*
  • Developers are solely responsible for the estimates and nobody can force them to change them.*
  • Estimates capture the best available knowledge at the moment of estimation and can be therefore significantly adjusted when more information is learned.*
  • Estimates are not promises of cost or duration.*
  • Developers select User Stories only from the Product Backlog and no other source.*
  • Developers are not allowed to create their own User Stories without the Product Owner’s approval.*
  • If too big, User Stories should be broken down so that one User Story can be feasibly done in a maximum of one Sprint. The events can take a maximum of 60 minutes per day.*

Sprint Review

Agenda

  • Present a summary of the finished Sprint.
  • Demonstrate and inspect the Product Increment.
  • Gather feedback on the Product Increment.
  • Present the strategy for the next Sprints.
    • Identify target and likely delivery dates.
    • Review the market situation to assess the most valuable work to be performed during the next Sprint.
    • Review the timeline, budget and capabilities for the next Sprint and Releases.
  • Adapt the Product Backlog.

ToDo

Stakeholders

  • Ask questions and provide feedback to the Scrum Team about the Product Increment.
  • Collaborate with the Scrum Team to optimize the value of the development work.

Product Owner

  • Invite key Stakeholders before the event.
  • Explain what has been done and what has not been done (respecting DOD).
  • Present the current state of the Product Backlog and changes made to the Product Backlog.
  • Track total work remaining and assess progress towards total projected goal and desired time limits.
  • Present changes in the budget, timeline, marketplace and the intended product use.
  • Describe what is the most valuable thing to do next.
  • Make changes to the Product Backlog.

Scrum Master

  • Ensure that the event takes place.
  • Ensure that attendees understand the purpose of the event.
  • Mediate the discussions.
  • Ensure proper Team Velocity is calculated and used.*
  • Keep the event within its time-box (preferably shorter).

Developers

  • Individually present the work that has been finished during the Development Cycle (respecting DOD).
  • Answer questions about the created Product Increment.
  • Describe what went well, what problems were encountered and how those were solved.

Rules

  • Stakeholders actively collaborate with the Scrum Team.
  • The Product Owner can freely rearrange and refine User Stories in the Product Backlog in reaction to gained insights.
  • Results are presented in a way that is understandable to the Product Owner and the rest of the Stakeholders (code presentations are generally prohibited).
  • The event happens immediately after the development work and can take a maximum of 2 hours.

Sprint Retrospective

Agenda

  • Inspect the last Sprint with regards to:
    • people
    • relationships
    • process
    • tools
  • Identify what went well, what went wrong and potential improvements.
  • Create a plan for improvements for the next Sprint.

ToDo

Product Owner

  • Participate in the last Sprint’s inspection.
  • Suggest improvements.
  • Suggest DOD adjustments.

Scrum Master

  • Ensure that the event takes place.
  • Ensure that attendees understand the purpose of the event.
  • If the Product Owner put a limit on planning, discuss the reasoning and impact with the Scrum Team.
  • Ensure that the meeting is productive.*
  • Mediate the discussions.
  • Participate as the person accountable for the Scrum process.
  • Encourage the Scrum Team to improve the process and practices.
  • Capture the improvement suggestions and actionable points for the next Sprints.
  • Keep the event within its time-box (preferably shorter).

Development team

  • Participate in the last Sprint’s inspection.
  • Suggest improvements.

Rules

  • The event takes place after the Sprint Review and prior to the next Sprint Planning.
  • DOD can by adjusted to improve product quality.
  • The whole Scrum Team must agree with the adjustments to the DOD.*
  • The event can take a maximum of 1.5 hours.