knowledge-kitchen

Scrum - Software Developers Role-Play Rugby

Software developers role-play rugby.

1. Agile manifesto
2. Scrum framework
3. Roles
4. Events
5. Communications
6. Team harmony
7. Conclusions

Agile manifesto

Concept

In 2001, at The Lodge at the Snowbird Ski Resort in Utah, 17 prestigious developers got together to talk shop.

• They emerged shortly thereafter with the Agile Manifesto, a very short document.

The text

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

-Agile Manifesto

Implementation

The Agile manifesto inspired a world of developers, but there were no details on how to implement it.

• Various practical implementation frameworks quickly emerged.

• Scrum is one of these.

Scrum framework

Concept

The Scrum framework is a recipe for achieving agile development by prescribing a strict set of…

• Roles

• Events

• Artifacts

Rugby Scrum

“Scrum” is a term from the sport rugby, where players huddle closely together, sweatily pushing and rubbing up against each other.

Roles

Concept

Scrum defines four distinct roles:

• Product owner

• Scrum master

• Developer

• Stakeholder

It is possible, although not adviseable, for one person to perform more than one of these roles.

Product owner

The Product Owner represents the business interests within the team.

• The Product Owner is the team member who communicates directly with the client.

• The Product Owner is the team member who maintains and prioritizes the list of features to be implemented.

Scrum master

The Scrum Master represents the Scrum framework within the team.

• The Scrum Master is a “servant leader”, not a manager.

• The Scrum Master ensures the team is following the Scrum framework.

Developer

Developers implement the work laid out by the Product Owner.

• Developers collaborate with the Product Owner to properly define and scope the work.

• Developers are autonomous and decide in what manner to do the work.

Stakeholder

Stakeholders are people external to the team who have an important voice.

• Stakeholders could be the client, or executives in the development company.

• Stakeholders can cause problems if not kept in close communication with the team.

Events

Concept

Scrum defines seven ritual events for different purposes:

• Backlog creation

• Sprint planning

• Daily scrum

• Backlog grooming

• Sprint review

• Stakeholder demo

• Team retrospective

Sprint timeline

Backlog creation

The Product Backlog is a list of features that the project is intended to implement. These featuress are written in a specific style and called “User Stories”.

• The Product Owner, by speaking with Stakeholders, drafts and maintains the Product Backlog at the start of a project.

• The features in the Product Backlog are ordered, with the most important User Stories on top of the list.

Backlog creation

User stories

User Stories are written in the following form:

As a ___, I want to ___, so that ___

• the first blank is filled in with a user role or type of user

• the second blank is filled in with a goal

• the third blank is filled in with a reason

These are written in non-technical language by the Product Owner.

Backlog creation

User stories

User Stories should follow the INVEST acronym:

• Independent - user stories do not depend on one-another

• Negotiable - can be canceled or changed at any time

• Valuable - meaningful stories

• Estimable - must be descriptive and small enough to be able to easily estimate work for it.

• Small - story is small enough to be completed in one sprint

• Testable - story contains enough clarity to be able to easily design a test for it

Backlog creation

User stories

Agile developers are perhaps overly confident in their ability to work with minimal documentation and specification. In practice, it is often the case that a User Story needs some more documentation and detail than a single sentence can provide, in order to avoid miscommunication and to align expectations of all involved.

Thus, User Stories often include a set of Acceptance Criteria.

• They represent the specific additional requirements for a specific User Story to be considered done.

• The Product Owner and Developers collaborativeley come up with this list of requirements for each User Story.

• For a given User Story, these are added to the Definition of Done, which is a set of requirements that all User Stories must satisfy in order to be considered completed.

Backlog creation

User stories

User Stories each often have an Estimation of Effort

• The Developers determine how much work is involved in the user story.

• Planning Poker is a popular technique for determining this.

Backlog creation

Spikes

Sometimes work needs to be done that is not end-user-facing, such as setting up a particular development environment.

Such a piece of work is called a Spike.

Sprint planning

In Scrum, work is divided into increments - a batch of work. Each increment is called a “Sprint”. Sprints typically last a few weeks.

• At the start of each Sprint, the entire team (including Product Owner) gets together and decides which features (i.e. User Stories) to work on in this Sprint.

• The Product Owner presents the list of User Stories in the Product Backlog, in priority order from top to bottom.

• The team discusses and collaboratively agrees on which User Stories to do in this Sprint.

• The Developers break up each User Story into discrete Tasks - units of work that are doable by one developer in about one day.

Sprint planning

The team discusses and collaboratively agrees on which User Stories to do in this Sprint. These are added to the Sprint Backlog.

• The Developers break up each User Story in the Sprint Backlog into discrete Tasks - units of work that are doable by one developer in about one day.

• Each task is assigned to a specific developer.

• The Developers get to work.

Daily Scrum

Every day, the Scrum Master and Developers get together to discuss status. Each Developer answers three questions:

• What have you done since last time?

• What are you doing now?

• Is there anything blocking your progress?

Blocking problems are addressed by the Scrum Master, who must seek help externally.

Backlog Grooming

Each Sprint, the Product Owner maintains the Product Backlog - adding new User Stories, modifying old ones, etc.

• At the mid-point of each Sprint, the entire team (including Product Owner) gets together to discuss these additions.

• The team discusses the new User Stories, and the Product Manager orders them appropriately in the Product Backlog.

• No User Stories are ever added to the current Sprint, but they can be addressed in subsequent Sprints.

Sprint review

At the end of each Sprint, the entire team (including Product Owner) meet to discuss the work that has been done.

• Unfinished User Stories are returned to the Product Backlog.

• The team agrees what is good enough to show to the Stakeholders.

Stakeholder demo

The entire team demonstrates the work to the Stakeholders.

• The Product Owner often leads the demo, althogh may do so, if helpful.

• Stakeholders give feedback, suggest additions, changes, etc.

• The Product Owner adds any new User Stories requested by the Stakeholders to the Product Backlog.

Team retrospective

The team discusses what happened in this sprint.

• How did the demo go?

• What worked well?

• What went poorly?

• How can we improve next time?

Artifacts

Concept

Scrum defines three artifacts:

1. Product Backlog - the list of all product features maintained by the Product Owner
2. Sprint Backlog - the list of features selected to be worked on this sprint
3. Increment - the sum of all work done in the current Sprint

We have already discussed these in the context of the events.

A bit more about the Increment

The Increment is the sum of all work done in the current Sprint. Each Increment is additive to all prior Increments.

In order for an Increment to have any value, it must…

• … be thoroughly tested

• … be usable

• … meet the team’s “Definition of Done”

In other words, any work done that is unreliable, unusable, or incomplete is not considered part of the completed Increment. Incomplete work should not be shown to Stakeholders in the demo.

Definition of Done

The Definition of Done is a description the team has agreed upon (and documented) of what it means for any feature to have been completely implemented.

• All user stories that are only considered done at the end of a Sprint if they have satisfied this definition.

• This definition commonly includes stipulations that the code has been thoroughly tested, integrated into the rest of the codebase, peer-reviewed, approved by the Product Owner, documented, merged into the trunk branch of the version control system, etc.

Communications

Concept

It is expected in Scrum that team members and Stakeholders always know the status of work currently being done.

• The primary document outlining the status of thee project is the Task Board.

Task Board

The Task board divides the activities in the current Sprint into the simple categories, such as:

• Sprint Backlog - list of all the User Stories that are being worked on this Sprint.

• To Do - a list of all the Tasks that have not yet been started,

• In Progress - a list of the Tasks that are currently in-progress.

• Awaiting Review - a list of the Tasks that are Awaiting review by another team member.

• Done - a list of the Tasks that have been reviewed and are considered complete.

The Task Board must be kept up-to-date at all times by the Product Owner and Developers.

Team harmony

Concept

It is critical that all team members be able to see the accurate status of all Tasks by all Developers.

• It is a good idea to draft a set of Team Norms that govern team member behavior.

• The entire team will notice when a member is not performing their duties, since it will obviously come up in the Dialy Scrum meetings and reviews of the Task Board.

• It is understood that the entire team will inform the boss early if any team member is not performing their duties, since it is a blocking problem.

Conclusions

Thank you. Bye.