So, what’s this Scrum that everyone is talking about?
Although it’s sometimes mistaken for one, Scrum isn’t an acronym.
So, what is it then? Scrum is a widely used framework for managing work. It is a collection of values, team roles, and rituals, used in combination to create working products iteratively. This is achieved by selecting items to work on from a backlog of items that need completing. The website Scrum.org is known as the “home of Scrum”.
Scrum began in the software industry and has since spread to many other areas including the military, the automotive industry, and beyond.
But this leaves a lot of questions about the details of the Scrum framework – what are the roles, what are the rituals and how exactly does it work?
What do people do?
Within Scrum there are 3 roles:
- Product Owner
- Scrum Master
- Development Team
The Product Owner is solely responsible for managing the backlog. This includes ordering the items to best achieve current goals and ensuring the development team understands all the items in the backlog.
The Scrum Master is the champion of the Scrum process, helping to maintain standards and keep the sprint moving. The Scrum Master also ensures a constant link between the Product Owner and the Development Team.
The Development Team is a truly self-organising team that turns the backlog items into releasable functionality. There are no titles in the Development Team as the team members are cross-functional and can do whatever is necessary to complete a sprint on time.
How does it work?
Scrum is designed for teams who break their work down in to actions that can be completed within timeboxed iterations, called sprints. Sprints last no more than one month and are most commonly two weeks long.
Progress is tracked throughout this period with a daily meeting known as a stand up. The stand up is timeboxed to 15 minutes and yes, you must stand up the whole time!
It defines a flexible, holistic product development strategy where a development team works as a unit to reach a common goal. This allows for adaptability when the customer inevitably changes their requirements, and trust me they will.
But what happens?
Backlog items are completed by the Development Team during the sprint; this is facilitated by four meetings:
- Sprint planning
- Stand up
- Sprint retrospective
- Sprint review
At the beginning of a sprint, the Scrum team holds a sprint planning event.
The team discusses and agrees on the scope of work it intends to complete during that sprint.
Items are selected from a backlog, keeping in mind that only items that can be completed in one sprint should be selected.
During the second half of the meeting, the Development Team identifies the detailed tasks required to complete those backlog items, resulting in a confirmed sprint.
At the end of the session the team picks a sprint goal, which should be the focus of the sprint.
Each day during a sprint, the team holds a stand-up with specific guidelines:
All members of the Development Team come prepared. Anyone is welcome, although only Development Team members have to contribute.
During the stand-up, each team member typically answers three questions:
- What did I complete yesterday?
- What do I plan to complete today?
- Can I see any impediments that could prevent me or the team from completing this work?
At the end of a sprint the team will hold a sprint retrospective, during which they will reflect on the past sprint, as well as identify and agree on continuous process improvement actions.
The main questions asked are:
- What went well during the sprint?
- What did not go well?
- What could be improved to make future sprints better?
This is usually facilitated by exercises involving a whole lot of post-it notes.
After the retrospective, the sprint review looks at the work that has been completed and it is demonstrated to interested stakeholders. Incomplete work should not be demonstrated.
This gives everybody a chance to provide feedback and look for possible improvements.
I’m not used to that, why would I need it?
There is a plethora of advantages to using the Scrum framework. The following are just some of the important benefits that Scrum provides to organisations, teams and products.
Better quality products
Scrum provides the framework for continual feedback, both internally within the Scrum team, and externally through frequent releases to the customer.
The regularity of testing and product owner collaboration helps to ensure the quality of the product is as high as possible.
Through the sprint retrospective, teams are able to improve specific factors such as processes, tools and relationships.
Decreased time to market
Traditional waterfall projects can take months just to deliver the initial documented requirements, whereas with Scrum working functionality is delivered at the end of each sprint. This means that the highest priority items are completed first and it avoids having to wait until the entire project is complete before functionality can be released.
Increase in team morale
As part of a self-organising team, people are free to express themselves creatively and are acknowledged for their achievements.
Having a product owner in the same team helps to identify technical/business priorities and breaks down organisational barriers.
In a cross functional team, each member is valued and is working towards a common goal. This level of collaboration means people are more willing to help other team members and go the extra mile to finish the sprint.
One of the most interesting benefits of Scrum is that it is not rigid. If part of the framework does not work for your organisation, then don’t use it. Replace it with something that does work or ignore it altogether if it is not relevant.
Companies should feel free to pick and choose in order to get the best out of Scrum.
There are many articles explaining how to transition in to Scrum, however, the best way to find out more is to use it and continually adapt your implementation.