Scrum Alliance has published seven versions of Scrum Guide in a decade since the first version was published in 2010. Each version has been a reflection of the changing landscape of software development processes. We have tried to summarize the salient pointers of every Scrum Guide and implications of the changes and updates in this blog. Please leave your comments, we will love to hear your perspective and take on the Scrum Guides. Wishing you all the best in your Agile transformation journey. Happy reading!!
1- Scrum Guide (1st Version, Feb 2010)
a. Highlights
-
-
-
-
-
-
- Defined Rules & Tips
- Chickens & Pigs
- Release Planning Meeting (Must-Do)
- Artefacts – Sprint Burndown and Release Burndown
-
-
-
-
-
b. Implication
A framework was introduced for the first time named as a ‘Scrum’, within which a complex product can be developed. Guide also articulated the core components of the Scrum for the first time and defined the “Must-Do” parts of the framework.
2- Scrum Guide (2nd Version, July 2011)
a. Highlights
-
-
-
-
-
-
- Definition of Scrum added
- Grooming Introduced
- Roles were defined
-
-
-
-
-
b. Implication
The roles for Scrum Master, Product Owner & Development Team were clearly explained in this version of the guide. Giving more stress on the Scrum Master role in order to service Product Owner, Development Team & Organization. First version of the guide was having tips for grooming, however in this version it was defined as a practice and hence became an essential part of the framework. Another impactful change in this version was – The Sprint Plan is a forecast and not a commitment i.e, we will demonstrate commitment to achieve the Sprint Plan and need to inspect and adapt to changes along the way.
3- Scrum Guide (3rd Version, Oct 2011)
a. Highlights
-
-
-
-
-
-
- Less emphasis on the ‘rules’ of Scrum.
- Page detailing the revisions made to the 2010 document was removed.
-
-
-
-
-
b. Implication
There was no major change in this version of the guide as compared with the previous version. However, there is less importance given to rules of scrum. Another change in this version was that the last page of the previous version containing details of the revision made to the original 2010 guide, was removed.
4- Scrum Guide (4th Version, July 2013)
a. Highlights
-
-
-
-
-
-
- Refinement replaces Grooming
- Product backlog items can be ready for a sprint after refinement.
- Sprint Planning is one event.
- Daily Scrum Questions refined.
- Value is reinforced in the Sprint Review.
- Artifact Transparency section added.
-
-
-
-
-
b. Implication
‘Refinement’ was thought to be much more appropriate than ‘grooming’ and hence the practice was renamed as ‘Refinement’. Similarly, the question asked in the Daily Scrum ‘what did I do yesterday?’ was refined to ‘what did I do yesterday that helped the development team meet the Sprint Goal?’
5- Scrum Guide (5th Version, July 2016)
a. Highlights
-
-
-
-
-
-
- Scrum Values (Respect, Commitment, Focus, Openness and Courage)
-
-
-
-
-
b. Implication
Scrum values were recognized as the lifeblood of Scrum, and crucially important to helping Scrum teams deliver.
6- Scrum Guide (6th Version, Nov 2017)
a. Highlights
-
-
-
-
-
-
- Daily Scrum Questions and Scrum Roles were refined.
- More clarity on time-boxes (events can be shorter)
- Sprint backlog should include one improvement item.
-
-
-
-
-
b. Implication
-
-
-
-
-
-
- Scrum Can be used by any team looking to solve complex adaptive problems.
- The famous ‘three questions’ in the Daily Scrum were recognized as just one way to run this event. Hence these were no more mandatory and teams can follow other great ways to run Daily Scrum.
- Scrum master is no longer responsible for “ensuring that the Scrum Team adheres to Scrum”, rather “helping everyone understand Scrum theory, practices, rules and values.” This redefines the Scrum master as coach, rather than a policeman.
- Include an improvement item in every Sprint.
-
-
-
-
-
7- Scrum Guide (7th Version, Nov 2020)
a. Highlights
-
-
-
-
-
-
- No more three questions in Daily Scrum.
- Term ‘Development Team’ replaced with ‘Developers’.
- Introduction of Product Goal.
- Three Commitments (Product Backlog, Sprint Backlog, Definition of Done)
- Self-Managing over Self-Organising.
- Sprint Planning Replanned
- No more Servant Leader.
- Simplification of Language and opening it to everyone, not only IT.
-
-
-
-
-
b. Implication
-
-
-
-
-
-
- Three questions on the daily scrum disappeared in the latest version of scrum guide. Motive behind this was that the Daily Scrum should focus on progress towards the sprint goal and share the next day’s actionable work plan. Removing the three questions will create focus and improve self-management as the developers can select structure and techniques that serve the purpose.
- Developers are the people in the scrum team that are committed to creating any aspect of usable increment. Hence the term Development Team was replaced by Developers to make all the stakeholders responsible for product goal.
- The Product Goal is to the Product Backlog what a Sprint Goal is to Sprint Backlog. That is, it describes the Product Backlog and gives direction to the Scrum team. Previously Scrum Teams used to focus on one Sprint Goal, whereas now a scrum team is expected to align the Sprint Goal to Product Goal in all the iterations.
- In the previous version of Scrum Guide, ‘Commitment’ was one of the five scrum values. Now this value is further refined to three specific commitments from three artefacts i.e,
-
-
- Commitment for the Product Backlog – Product Goal.
- Commitment for the Sprint Backlog – Sprint Goal.
- Commitment for the Increment – Definition of Done.
-
-
- Self-organisation gives way to Self-managed teams, that means the teams decide internally ‘who does what, when and How.’
- ‘Why’ has been added as a discussion point in the Sprint Planning in addition to ‘What’ and ‘How’’. This will help developers to understand how this sprint will increase the Product value.
- Scrum Master role is redefined:
-
-
- Scrum Master is accountable for establishing Scrum.
- Scrum Master is accountable for Scrum Team’s effectiveness.
-
-
- Apart from these Scrum Master should also serve the larger organisation. They need to bring product vision from top level to ground level and enable its execution.
-
-
-
-
-
Keep practicing AGILE!
Atul Mishra
