When should I use Scrum?
When you want to deliver a product of known quality, have some predictability on upcoming work, and have people who can fulfil the three roles (Product Owner, Development Team and Scrum Master).
When might I avoid Scrum?
When the loss of efficiency arising from taking regular time out to improve the process and adjust the plan; while working in teams of mixed specialisms; is not outweighed by the benefits in building the right thing. Scrum is designed for software product development, and adds most value when there is an element of uncertainty in the requirements and technology. If the work you are doing is different then a Kanban model allows complete flexibility in evolving a bespoke process relevant to the work at hand.
Scrum is not a good fit for delivering a fixed plan where scope and time are not negotiable. Scrum seeks to solve the problem of maximising the value delivered over time by providing frequent opportunities to ask “what is the best course of action today, based on everything we have learned so far?”.
Elements of Scrum
There are 3 defined roles, 3 defined artefacts, and 5 events in Scrum. They are supported by some implied elements. You need to have an understanding of them, and agreed who is in the roles and how you are going to apply them.
Roles
Product Owner: The single individual responsible for the value of the product. Focusses on how to get the maximum value as well as optimising Total Cost of Ownership (TCO) and Return on Investment (ROI).
Development Team: The cross-functional, self-organising group of people (optimally 3 – 9 members) who have the necessary skills and knowledge to build the product. The skills required from the team are dependent on the product.
Scrum Master: The servant leader who ensures people use the framework, and removes impediments (blockers) that people can’t resolve themselves. The Scrum Master also coaches the team, product owner and organisation.
Together, these three roles are known as the Scrum Team.
Artefacts
Product Backlog: The ordered list of work that needs to be done to improve the product. This is managed by the Product Owner and refined collaboratively with the stakeholders and the Development Team. There is one Product Backlog per Product, regardless of the number of teams building the Product.
Sprint Backlog: The list of work that the Development Team need to accomplish in the Sprint.
Increment: The potentially releasable product that is created during the Sprint. It will be the original product as well as what has been added to it in the Sprint.
Events
All the events are time-boxed to improve focus.
Sprint: a time-box of one month or less to build the increment, during which all the other events occur. It is helpful to have the duration consistent, to help improve predictability and reduce risk. A new Sprint starts immediately after the previous Sprint is completed.
Sprint Planning: A meeting to agree on and plan the work to do in the Sprint by the Scrum Team. The objective of the Sprint is agreed and used to build a Sprint Goal. The Development Team will collaborate with the Product Owner to pull work from the Product Backlog and forecast the activities needed to build the Increment.
Daily Scrum: A 15-minute Development Team synchronisation meeting, that occurs every working day at the same time and the same place.
Sprint Review: A meeting at the end of the Sprint where the Scrum Team and stakeholders collaborate to inspect the increment and adapt the Product Backlog. It is not a status meeting; however, the marketplace and potential use of the product and timelines are discussed.
Sprint Retrospective: A meeting at the end of the Sprint for the Scrum Team to review how the Sprint went and plan changes to make in the next Sprint.
Implied Events and Artefacts
For Scrum to work there are some implied artefacts and events. They are defined in the Scrum guide, but not as official events or artefacts, however for the Sprint to succeed they are very important.
Product Backlog Refinement: A continuous collaborative activity to add detail, estimates and order to the Product Backlog. It is implied, as it is not possible to have a Product Backlog without keeping it up to date.
Sprint Goal: A broad objective of what is going to be achieved during the Sprint. It is an implied output of Sprint Planning, as it is described in the Scrum Guide although not as an artefact
Definition of “Done”: The shared understanding of what work complete is, so that the Increment is potentially releasable. When multiple teams are working on the Product this must result in a mutual “Done” that creates a single potentially releasable increment. It is implied in that the Product must be potentially releasable.
Shape of a Sprint
The typical representation of a Sprint is two circles, normally only highlighting the artefacts. This is to highlight that the Daily Scrum and the Sprint are feedback (or continuous improvement) loops.
Getting started
To get started you need to have defined:
- Who is your Product Owner
- Who is in your Development Team
- Who is your Scrum Master
- Created enough Product Backlog for the first Sprint (that is understood by the whole Scrum Team)
- Agreed a Sprint length
- Agreed a Definition of Done
- Understood the starting product if you have one
- When and where you will have your Daily Scrum
- When and where you will have your Planning, Review and Retrospective meetings
It is helpful to:
- Understand who your stakeholders are
- Have agreed how you will refine your product backlog
- Have defined the tools and environments that will be used to create the Increment.
At Agility in Mind we have worked with many different teams, from those just starting out to experienced teams looking to revitalise their approach. Our Professional Scrum Training courses are a great way to quickly give teams the tools they need to get started or make sense of what they have been doing. This can be combined with follow-up coaching to help teams apply what they have learned and maximise their effectiveness.
