Back in the Scrum
With all the Rugby back on at Twickenham & passing the BCS Foundation Certificate in Agile v2 exam, it's definitely time for a quick Scrum blog post.
I had previously achieved Certified Scrum Master with Mike Cohn's excellent course, so this was a chance to update my softer project management skills.
The Agile course was a great refresher as it focussed on Scrum over the Kanban & DSDM flavours and covered some of what's new in the 2020 Scrum guide (appreciate its now 2021 but the content is relevant!).
Reboot
The 2020 Scrum guide has gone Lean and stripped back some of the dogma that previously led to unnecessary discussions about the 'right way to do Scrum'.
Treat it as a Rule Book not a Play Book
What got canned?
- The 3 questions at the Daily Scrum AKA Stand Up
(what I did yesterday/today/blockers...)
The focus now should be on what each person is doing to achieve the Sprint goal 🎯
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
e.g maybe 2 questions like:
Why isn't the top user story done?
How can we as team get it over the line in this Sprint? 🏉
2. Accountabilities instead of 'Roles'
Instead of 'roles' Scrum now defines three 'accountabilities' within the Team:
the Developers, the Product Owner and the Scrum Master.
The idea here is to get away from a role in a scrum team being your official job title and to emphasise these are roles with defined accountabilities.
3. True Leader instead of Servant Leader
The 2020 update expands the Scrum Master's role into 'a leader who serves' at a higher organisation level almost like an Agile Coach:
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organisation.
The idea is to remove the perception that all the Scrum Master does is run stand ups and unblock things. They need to be Active not Passive.
4. Parking Lot After Daily Scrum
The previous Scrum guide stipulated these 'offline' conversations should take place immediately after the Daily Scrum. The team can now decide the timing, a good thing as Stand Ups can end up dragging on to 1 hour meetings 🥱.
These are just 4 updates, there are many more you can see here on the Scrum Inc website.
The 3-5-3
The new formation is:
- 3 Accountabilities/Roles - Product Owner, Scrum Master & Developers
- 5 Events - Sprint, Sprint Planning, Daily Scrum, Sprint Review & Retro
- Note: Backlog refinement is not an official Scrum event
- 3 Artifacts - Product Backlog, Sprint Backlog & Product Increment
Goals Galore
The 3 Artifacts now have a Commitment, for transparency, focus and to measure progress:
- Product Backlog >> Product Goal (new in 2020)
- Sprint Backlog >> Sprint Goal
- Product Increment >> Definition of Done
Product Goal
The 2020 update introduces the Product Goal to enable long term focus for the Scrum team:
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
Product Owners will invariably want to connect this goal to the product strategy or vision to ensure at an executive level it's meeting user and business goals.
For the Product people out there be sure to check out Roman Pichler's website
and his amazing book Strategize.
...a product goal is best used to describe a specific and measurable benefit or outcome a product should create in the course of the next two to six months - Roman Pichler
Sprint Goal
Each Sprint aims to bring the product closer to its overall goal & vision.
🤔 Defining precise Sprint Goals can be difficult, especially if the Scrum team works on multiple products (or has to stretch across BAU support). Some ideas here from Mike Cohn's excellent website 👇
- Try setting 80% of the Sprint Backlog's PBI's as part of the Sprint Goal
- Leave remaining 20% other project or BAU work
- If on track all good - otherwise drop the 20% and focus on goal
- Chop and change % and see what works
- Try a Sprint Theme instead (word, phrase, picture, song or movie)
Definition of Done
Inside the Sprint backlog each Product Backlog Item completed (to a Definition of Done) in the Sprint adds a Product Increment of value.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
This way we know each Product Item is potentially shippable as it's good enough to be released to production 🚀!
Product Backlog >> Sprint Backlog
Some of the questions I had on the course were around Sprint Planning.
What should we put in the Sprint Backlog?
How do we prioritise which PBI's should go in?
How does this align with the Sprint & Product Goal?
This picture gives a good tip to get started, use some sort of MoSCoW prioritisation matrix, assess team capacity and then carve up the PBI's in the Sprint Backlog with a % of each:
GitHub Projects
In practice an Agile tracking tool like the excellent GitHub Projects beta can help you visualise this.
The flexibility of GitHub Projects means instead of fixed MoSCoW values you can create any sort of Priority field you like and even tie it in to your Product Goal / Theme using GitHub Emojis.
So when your Sprint backlog has been estimated you can assess the % of each priority to ensure it reflects the product owners expectations and works towards the Sprint goal.
You can take the theming further and apply it to your Effort estimation, how about Animal sizes instead of T-shirts - the sky's the limit!
Iceberg
Finally, a great way to visualise that product backlog and goal is the Iceberg.
This gives you enough vision of what value add increments are in the current sprint & the bigger picture of the next release. As we go underwater the backlog is less clear as has yet to be prioritised and estimated but we know it's coming 🦈.
As all projects are subject to change there's no need to fully estimate the entire Iceberg until the Scrum team need to (Just in Time & Just Enough).
We need just enough visibility to see far enough underwater to avoid the issues, as the team dives faster, the deeper we need to look!
writing a novel is like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way.
- E. L. Doctorow
Wrap Up
The 2020 Scrum Guide changes are definitely an improvement and really fit into more a modern and flexible Agile approach to projects.
It's always worth checking out what's new in this space even if you have been though months & months worth of Sprints in the past!
If you want to learn more definitely check out below 👇