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

User Stories each can have a set of Acceptance Criteria.

• These provide additional detail about what specific features are necessary for the user story to be satisfied.

• This represents the minimum requirements for the User Story to be considered done.

• The Product Owner and Developers collaborativeley come up with this list of requirements.

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 called “sprints”. Sprints typically last several 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, 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.

Events

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.

Events

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.

Events

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.

Events

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?

Communications

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.

Communications

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.