What is Scrum?
Simply put, Scrum is an Agile framework for developing complex products.
While it is often used for developing software, it can be used for any complex products, especially where requirements are not known or may change frequently.
Right at the start of a project we know less than we’ll ever know about the requirements. Scrum accepts this and doesn’t try to define all the requirements up front – like you would do in the Waterfall method. Instead, Scrum uses an empirical approach of Transparency, Inspection and Adaptation.
• Transparency – the people involved in the Scrum process should be able to easily see the state of the process and the artifacts involved.
• Inspection – looking at the process to determine what went well and what could be improved.
• Adaptation – based on the results of Inspection, we make changes so that the Scrum process runs more smoothly next time. This way we are constantly and iteratively improving the process.
So requirements are discovered and refined as the project progresses.
Scrum aims to regularly release potentially shippable software increments using a series of meetings, with associated roles and artifacts.
We’ll look at these in more detail in subsequent posts, but the basic process is as follows:
1. The Product Owner creates a prioritised list of product features they’d like. This is called the Product Backlog.
2. At the Sprint Planning meeting, the team takes a selection of these features from the top of the list to create the Sprint Backlog.
3. These features are what they think can be completed during a Sprint – a 2-4 week period of development.
4. The Development Team works to create the product increment.
5. The team meets daily at the daily Scrum, where they report on progress.
6. The Scrum Master helps to coach the team in the whole process, while removing impediments that they may encounter.
7. At the end of the Sprint, the work we have completed so far should be potentially shippable I.e. Released to customers.
8. Following this, the Sprint Review meeting allows the Stakeholders to view what was completed during the Sprint and for the team to discuss any issues they had. It also enables the Product Backlog to discussed.
9. The Sprint Retrospective meeting allows the team to Inspect the Sprint to identify any issues and what can be improved.
10. Backlog Refinement isn’t an ‘official’ Scrum meeting, but many teams find it useful. It ensures the Product Backlog accurately reflects the Product Owners needs by removing, creating and prioritising User Stories.
In Duncan’s next article he explores “What are the roles are in Scrum?”
Duncan Halley is a web developer and certified Scrum Master (PSM I). You can read his blog here.
Follow him on Twitter: @duncanhalley
