The Scrum development methodology is an iterative and incremental software development methodology. Scrum has a simple set of roles and responsibilities to be followed and has nothing to do with rugby. Scrum is based on prioritizing a backlog and committing to doing a set of work in a short fixed time period and no other work to be done in the space of time.
This approach is in direct response to the traditional waterfall method which didn’t react to change. Scrum teams can easily react to new requirements/change as they have only committed to two or three weeks of work.
A Scrum team will have a Scrum Master who is there to help the team implement the methodology and maintain the practices. The business is represented by a Product Owner who prioritizes the backlog and interacts with the Scrum team providing any extra information.
Scrum has a set of rituals that need to be maintained to be considered Scrum such as Daily Stand-Ups, Sprint Planning, Demos and Retrospectives. To see how large companies do Scrum check out LeSS.
Scrum Development Methodology Framework
Scrum development methodology is a process framework used for managing product development. It is not a process or technique for creating products but a framework which you can employ various processes and techniques. The framework consists of Scrum teams which include a Product Owner, Scrum Master and development team with each of their own individual rules, roles, events and artifacts.
3 Pillars of Scrum
Scrum is based on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
- Transparency – Aspects of the process must be visible to those responsible for the outcome.
- Inspection – Artifacts and progress should be inspected frequently but should not impact performance
- Adapt – If after inspection it is determined aspects of the process or product deviate from what is expected, they should be adjusted with minimum interruption.
Scrum Development Methodology Roles
The product owner is the person responsible for managing the backlog. Product Owners represent the business and are expected to prioritize the backlog matching business needs. The business needs to accept the Product Owners decisions and cannot contact the Scrum team directly.
- Creating user stories
- Ensuring stories are clear for team
- Prioritizing product backlog items
- Ensuring product backlog is visible for all
The development team are a self-organized team empowered by the organization to organize and mange their own work. The purpose of this is to create a Synergy within the team as they feel empowered. The development team can be cross-functional with all skills required to deliver the increment. Scrum recognizes no titles for team members other than developer and no sub-teams. Scrum teams should be kept small it is recommended no more than 9 developers should be on a Scrum team.
- Delivering releasable increments of “done” product at end of each sprint
The Scrum Master is a servant-leader for the development team. The main responsibility is to assist the team in practising Scrum by ensuring they aware of the principles and follow them when applicable. The Scrum Master also acts as a shield for the development team from external distractions/interference.
- Assisting product owner with backlog management
- Understanding product planning in an empirical environment
- Facilitating Scrum events as requested or needed
- Coaching team in Scrum processes and techniques
- Removing blockers to development team progress
Scrum Development Methodology Ceremonies
There are a number of ceremonies to practice Scrum efficiently. The ceremonies are to create regularity and to minimize distractions on the development team such as meetings. Each ceremony will have a maximum duration to prevent them disturbing the development work. Besides the sprint other ceremonies are used to review and adapt where required.
Duration: 1-2 Hours
Backlog refinement is also refereed to as “backlog grooming”, “story time”, “estimation session” or even “backlog maintenance”. Its core purpose is to prepare the Product backlog for Sprint Planning. The Product Owner will identify stories that could be in the next sprint. The team will review these stories to ensure they are correctly estimated and can be selected for the next Sprint.The Scrum Master will introduce estimating games such as…
- Planning Poker
- Estimating Game
After the refinement session stories should be ready to be selected in Sprint Planning for the next Sprint.
Duration: Maximum 8 hours for a one-month Sprint
Sprint Planning is the process of selecting what is to be worked on in the next sprint. It is the Scrum Masters responsibility to ensure Sprint Planning occurs and follows time boxed recommendations. Sprint Planning aims to answer two questions…
- What can be delivered in the upcoming Sprint?
- What work is needed to deliver the Sprint?
A Sprint Goal is determined by the Product Owner which is the objective of the Sprint. Then stories from the product backlog are selected by the team that can help achieve the Sprint goal. The team is responsible for selecting the amount of work they can implement without accruing technical debt. Once selected these stories create the Sprint backlog which is the work selected for the next sprint. The Sprint backlog is then prioritized in a way the tasks are organized as they will sequentially be worked on by the team.
Duration: Minimum 2 weeks, Maximum 4 weeks
The Sprint is when the work actually gets done and is the most important Scrum ceremony. Sprints will have a set duration which is to be strictly obeyed regardless if work is completed or not. Remaining work would need to be prioritized again to be added to another sprint. A new sprint starts immediately after one is complete. Sprints consists of Sprint Planning, Daily Stand-Ups, Development work, Sprint Review and the Sprint Retrospective. Only the Product Owner has the power to cancel a Sprint although they may do so under the influence of the business, Scrum Master or development team. The main reason a sprint would be cancelled if the sprint goal became obsolete but as a general rule sprints shouldn’t be cancelled.
Duration: 15 Minutes
The daily stand-ups are 15 minute event which are held each morning at the team area. It is crucial that only team members speak at the daily stand-ups which is a rule enforced by the Scrum Master. Each person is to answer the following 3 questions and should not take more than a few minutes with their update…
- What I did yesterday
- What I plan on doing today
- Any blockers to report
This daily stand-up is an absolute must in any Scrum development methodology as it improves communication and identifies blockers which can be acted upon quickly.
Duration: Maximum 4 Hours for one-month Sprint
The Sprint review/demo is an opportunity for the team to demonstrate the work completed in the previous sprint to all stakeholders. The Product Owner will explain the Sprint goal and then the development team will explain issues they encountered and how they overcame such issues. The development team will then demonstrate the product created in the Sprint.
Duration: Maximum 3 Hours for one-month Sprint
The Sprint Retrospective is where the process is reviewed on what went well and not so well. It occurs after the Sprint Review and prior to the next Sprint Planning. The purpose of sprint Retrospectives is as follows:
- Inspect previous sprint with regards to people, relationships, processes and tools
- Identify potential improvements that can be made
- Create a plan for implementing the identified improvements
The Scrum Master will be the main driving force behind Sprint Retrospectives as they will understand it is a crucial aspect of Scrum.
Scrum Development Methodology Artifacts
User stories are how the business/product owner write out requirements for a product. A user story is written in the viewpoint of the end user and follows the following format…
As a , I want so that
As a user, I want to download videos so that I can store videos on my .
As an systems administrator, I want to monitor photos uploaded so that I can confirm they are appropriate.
The story format leaves the actual technical implementation up to the developer. Stories will be reviewed in refinement sessions to ensure the development team understand the user requirements and the expected behaviour of the end product.
Epics are a group of user stories grouped together to achieve the same business goal/product.
The Product Backlog is an ordered list of all user stories created by the business. It should consist of every requirement, changes, improvements; it is never complete. As the Product evolves the stories will change but will be can be continuously added to the Product Backlog.
The Sprint Backlog consists of the user stories selected from the Product Backlog to be in the next Sprint. The Sprint backlog is a forecast by the development team what can be expected to be completed in the next Sprint. Only the development team can change the Sprint backlog during a Sprint.
The Scrum board is where visibly it can be seen the current progress of the Sprint. A typical Scrum Board will consists of:
- Committed Backlog Items
- Tasks Not Started
- Tasks in Progress
- Tasks Completed
Some companies will have an actual whiteboard with posits representing stories that are moved by developers as they complete them. Other companies use JIRA which is a software application that enables you to mimic this using boards and backlogs. I personally highly recommend using JIRA for ease of use and efficiency.
The burn down chart is a quick way of determining if a sprint is going to plan or not. The diagonal line running from top to bottom represents ideal burn down and is compared to the jotted lines of actual work done. The burn down chart is widely used by teams following the Scrum development methodology.
Release Planning is performed by the Product Owner where they plan at a very high level plan for multiple sprints. Releases will consist of multiple increments from Sprints. To create accurate release plans the Product Owner requires…
- Prioritized backlog
- Team velocity
- Conditions of satisfaction (goals for schedule, scope, resources)
Like the Scrum Product Backlog the Release plan is not a static plan.
Definition of Done DoD
When a Product backlog item is “Done” everyone must understand what “done” means as this can vary from scrum team to Scrum team. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.” The Definition of Done is the standard for expected quality of the team and would be expected to expand to include more strict criteria as the team evolves.