3.1. Applying Scrum: The Missing Ingredients
This chapter of the series dives into the realities, and often difficulties, of applying Scrum practices in organisations and teams. As such, it assumes some prior knowledge of Scrum. If you need a Scrum overview or refresher, the official Scrum Guide will provide the basics required for this chapter to make sense.
1. The Incomplete Scrum Recipe
The hit TV competition The Great British Bake Off tasks talented bakers to knead, whisk and roll their bread doughs, cake mixes and sweet pastries to produce increasingly delicious looking and elaborate bakes. The most dreaded of these tasks is known as the “Technical Challenge”. Although each baker is given the required ingredients to produce their bake, there’s a catch: the provided instructions are incomplete. The steps listed often leave the bakers with more questions than answers, and without any other help, they rely on their baking instinct to see them through. It’s no surprise that this task often results in poor quality, and sometimes inedible, bakes.
Those adopting Scrum risk tripping up in the same way. Look back at the Scrum Guide. It describes in meticulous detail what can and can’t be done during a Sprint. It makes clear the role of each “player” and their interactions in the “game”. But it neglects to explain how the moves are performed. How does a Product Owner decide the priority of the backlog? How does the Development Team go about evaluating the items on the backlog? How does a Scrum Master ensure Scrum principles are being properly practised?
The Guide sidesteps the responsibility of detailing specific methods by declaring that Scrum is a “process framework” and not a “definitive method”. Additionally, it clearly states: “Specific tactics for using the Scrum framework vary and are described elsewhere”. Exactly where “elsewhere” is is unfortunately never made clear. It’s no surprise then that many of us, like the bakers in The Great British Bake Off, end up falling back on previously learned instincts and behaviours.
2. Additional Scrum Events
The bold claim that Scrum Events are designed to “minimise the need for meetings not defined in Scrum” doesn’t hold up to the reality of practising Scrum. Consider that the Product Owner is responsible for delivering the product increment to the customer, whilst ensuring the items on the Product Backlog are prioritised correctly and have enough detail to be accepted by the Development Team. That’s sensible of course, but… when does this happen? As such, there are (a minimum of) two additional events which members of the Scrum team must engage in:
- The Development Team must review the Product Backlog, to feedback to the Product Owner that there is enough detail in the items and that the items are reasonably sized (i.e. they can be completed within a Sprint)
- The Product Owner must deliver the product to the customer, gather feedback, reprioritise the Backlog accordingly and make the newly-prioritised Backlog visible
In this post, we’ll focus on the first of these new events.
3. Product Backlog Review
In the transparency-led world of Scrum, teams and stakeholders will see new customer needs manifest through an ever-changing Product Backlog. New items will appear, previously important requests will drop whereas those entries once considered as having little value may rise up the Backlog.
The Development Team must find a way to cope with this dynamism of the Product Backlog and ensure the highest valued items are discussed in a timely manner. The purpose of the review is to ensure the team understands the request well enough to accept it into an upcoming Sprint. As well as going through the detail of the work and clarifying the “Definition of Done” for the request, many teams will also use this opportunity to estimate the size of the work. It’s worth pointing out that despite the prevalent use of Story Points, Scrum doesn’t insist on any estimation at all, never mind ascribing a particular unit of estimation.
Irrespective of how the team chooses to schedule these sessions, the matter of who should attend is the next one for the team to resolve. If the team is made up of three engineers, then it’s easy to conclude that all three should attend. But if the team is on the larger end of the scale with eight or nine developers, should all of them attend?
It’s tempting for a team to decide for only a few engineers to input into the estimations as the cost of taking the whole team may be deemed to be too high. Why have all engineers in a room when the majority of them could be working on achieving the current Sprint Goal? And besides, who enjoys such Backlog review sessions? However, choosing to have only a few engineers attend comes with its own risks.
Firstly, it would likely be the more experienced engineers who would attend on account that they have the most in-depth knowledge of the technical challenges and the trust of the whole team. This would cause two problems: less experienced engineers would never learn how to estimate and the senior engineers would never benefit from the knowledge that their junior colleagues have.
This would lead to the second issue in that any estimates would be given with incomplete knowledge of the technical problem, as well as estimates which only a few engineers have signed up to. Would the engineers who estimate add buffers onto the tasks to allow for the difference in skill level between them and those not in attendance? If not, are the engineers expecting every member of the team to be able to work to the estimates that only they themselves are comfortable giving?
Thirdly, the idea that having a few engineers attend as a cost-saving measure does not hold. The team must at some point gather to understand the work request, any estimates and reasoning behind why this work was accepted. And this requires either another meeting or for some documentation to be written and then read by the team. This is another time cost the team will have to pay, with the added costs and risks of the handover of knowledge.
Finally, given that each estimate will normally be provided with an idea of how the technical solution will look, this could result in a situation when the senior members are dictating the solution to the other engineers, stifling professional growth and creativity for everyone else. Although this is a trade-off for the team to decide upon, it’s clear that finding a solution where every member of the Development Team can review and input into the Backlog is the most desirable one.
Whereas this post focused on the additional activities a Scrum Development Team must undertake, the next one will look at the role of the Scrum Product Owner, and scratch the surface of perhaps the most important element in any great team: the relationship with the customer.
About Agile Bites
Agile Bites is a series of posts written by Mohammed Rizwan which, when put together, intend to serve as a course for individuals and teams. Starting from Agile basics, we’ll move to more challenging topics such as Kanban’s work-in-progress limits and Scrum anti-patterns, whilst attempting to figure out exactly what an MVP is.
Follow Agile Bites to ensure you don’t miss a single post: https://medium.com/agile-bites
