What is Scrum?
In the last article, I explained what Scrum was supposed to be. As usual though, Scrum has changed in the last 30 years. So, what is Scrum now? Since 1986 when Scrum was initially defined it has gone through a slow process of institutionalized misunderstanding. We have defined roles in the Scrum process and even created one specifically for telling us what Scrum is. Many of the original themes are now diminished or completely missing and strict process has entered the picture. The question is have we gone too far or have we not gone far enough.
We All Play Different Roles
Scrum has developed several roles including a role that exists for the sole purpose of instructing the team on proper Scrum practices.
The Product Owner, much to the chagrin of Business Analysts, is a defined as a combinatory role consisting of the responsibilities of marketing, Stakeholders, Project Managers, and Business Analyst. Typically a Business Analyst assigned to the Team is placed in this role. The Product Owners primary responsibility to the Team is the maintenance of the Product Backlog. The backlog requires constant adjustment and refinement.
The Team usually consists of Developers and QA Testers. The members of the Team typically fulfill their usual roles in a software development project. The one change is the level of involvement in the selection, assignment and execution of the work being done within the Sprint.
The role of the Scrum Master is simply to guide the team and guard the process. Scrum Master is often also referred to as being a shield and bulldozer for the team. In this secondary capacity, the Scrum Master is capable and empowered to protect the Team from outside disruptions, such as the Product Owner, and even to apply pressure to individuals or groups that may be preventing forward progress during the course of the Sprint. The job of the Scrum Master is simply to ensure that everyone is playing by the rules. Anyone in violation of the rules set forth by the team is gently reminded of the rules and asked to respect the Team’s agreement of how the process is to be implemented.
The Product Backlog is a prioritized list of all the Features being planned for the current Project.
The Sprint Backlog is a list of all the Features being worked on during the current Sprint.
A Sprint is the representation of the iteration cycle in Scrum. Sprints are essentially a time-boxed slice of work at the end of which working software is supposed to be produced.
The Sprint Board is a representation of work currently being done. Generally the board is laid out as a series of columns representing state (Development, Testing, Done, etc.) and rows representing the individual Features.
A Feature, in the context of this article, is the unit of work committed to during a sprint.
Working Software in Agile holds a somewhat unique definition. It doesn’t mean that the software is necessarily deployable to production. It does mean that the Features that were committed to are complete and have passed QA Testing.
The Meet Factory
Scrum exclaims to reduce overall meetings disrupting team productivity. It, however, declares several meetings that are officially part of ceremony and one meeting that is less ceremony but just as important.
The Daily Scrum is held every working day of the Sprint. Three questions are typically asked of Team members:
- What did you accomplish yesterday?
- What are you working on today?
- Are there any blockers?
The goal of the Daily Scrum is to inform the Team of the Sprints overall progress and alert the team to anything that might endanger the Sprints on time completion.
Product Backlog Review
This meeting is an adhoc meeting. Product Backlog Review occurs when the Product Owner wants to review upcoming Features with Team in an effort to refine, estimate, and prioritize the Product Backlog.
In Sprint Planning, the Product Owner provides to the Team the Product Backlog. The Team chooses from the Product Backlog, and adds Features to the Sprint Backlog. The chosen Features are considered committed to.
Sprint Review is an opportunity for the team to demonstrate the work that was completed in the last Sprint to the Product Owner and any Stakeholders that are interested. This is the Teams first chance to receive feedback on work completed. Sprint Reviews are generally held before Sprint Planning as they could affect the Product Backlog’s priority.
In the Sprint Retrospective, the Team discusses how the Sprint was executed. Generally, the Team attempts to set a few goals during this meeting. The goals are often to focus on discouraging some practices known as “what to stop”, encouraging some practices known as “what to continue”, and testing out some practices known as “what to start”.
Generally Associated Practices
Although not defined as part of Scrum, at least not anywhere I can find, certain practices accompany Scrum so often that I will include them in the description of what has become of Scrum.
While Scrum does not define what type of requirement definitions to use, Scrum is almost always implemented with User Stories.
A User Story is a simple requirement style consisting of three parts. As a Role, I want Feature, So that Reason
A Theme is a collection of User Stories. Do you see the connection?
An Epic is a collection of Themes. It is not uncommon to require more than three levels of detail when breaking down requirements. For that reason Teams will often create nested Epics, Themes, and User Stories.
There are a few terms whose true meaning can only be defined by the Team.
Definition of Done
The Definition of Done must be defined by the team. Definition of Done provides a clear understanding of what “done” means. An example of the Definition of Done would be:
“A work item is considered done when the development has been completed, has passed QA testing, and has been approved by the Product Owner.”
This definition can be as loose or as strict as the team requires.
Definition of Ready
The Definition of Ready is very similar to the Definition of Done. The Definition of Ready is different in that it describes the requirements for a work item to be considered ready for commitment in a Sprint. An example of the Definition of Ready would be:
“A work item is considered ready when the User Story is estimated by the Team, and the Product Owner has prioritized the User Story in the Product Backlog”
This definition can be as loose or as strict as the team requires.
The goal of this post was to describe what scrum has become. If you or you’re Team are currently implementing Scrum, then I hope all of these terms are familiar and that the definitions are inline with what you’re Team is working with. In the next article we will discuss How businesses use the practices and roles I have defined here. I will explain, finally, why Scrum sucks.