In Scrum classes we often ask the attendees to draw a picture of the Scrum framework, in order learn what their current understanding of the framework is. In many cases people are close to remembering the three roles, three artifacts and five events. But they also bring forward many related elements that are important or even indispensable to support the Scrum framework, but are not roles, artifacts nor events.
1. The Scrum team
The Scrum is the whole of the Development Team, the Product Owner and the Scrum Master. The Scrum team has an affinity with the family of roles, yet it is not a role in the Scrum framework. Notice how the Scrum guide references the Scrum Team and the Development team specifically when addressing their distinct accountabilities:
- The Development team forecasts the Product Backlog items for the Sprint, the Scrum Team crafts a Sprint Goal.
- The Scrum Master is servant-leader for the Scrum team.
- The Daily Scrum is a 15-minute time-boxed event for the Development team. At it, the Development team plans work for the next 24 hours.
(This list is just a random set of examples. Refer to the Scrum guide to discover more).
2. The Stakeholders
I have not witnessed a PSM-I training where the class did not add “Stakeholders” to their drawing of the Scrum framework. There are different kinds of Stakeholders (the business, customers, users,…), but with Stakeholders students usually mean “the business people trying to influence product development through the Product Owner”. To add these Stakeholders to the Scrum equation makes total sense considering the Stakeholders’ powerful impact on the product. Stakeholders are related to the family of roles, but they are not a Scrum role. This is because (business) Stakeholders do not actively contribute in the creation process of the increment during the Sprint. When the Stakeholders are invited by the Product Owner to the Sprint Review, they contribute by inspecting the increment so they can provide feedback on product value. The Stakeholders play an important role in the background with the Product Owner acting as a lens towards the Development team.
3. The Definition of Done
The Definition of Done is not a Scrum artefact, but it is an element of Scrum that supports increment transparency. It is an extremely versatile Scrum element as I described in an earlier blog: “The Definition of Done, The Swiss army knife of Scrum”.
Much like artifacts, the Definition of Done is inspected and adapted frequently, but despite that, it is not an artefact as it isn’t part of the product value stream in the way backlogs and increments are. Although the DoD is used to inspect and adapt and creates transparency, the real thing that is used for inspection and transparency is the Increment. The Definition of Done plays a fundamental and indispensable role in Scrum as it enables the framework’s primary and most important goal to deliver “done” software every Sprint.
4. The Sprint Goal
The Sprint goal is not an artifact but an objective set for the Sprint. The Sprint Goal is crafted by the Scrum team during Sprint Planning and guides the Development team to why it is building the Increment while offering them solution flexibility. The Sprint Goal is not an artefact as it is not inspected or adapted, i.e. it is not used to do empirical process control. It is crafted and then used as a guide for the inspection/adaptation throughout the Sprint.
5. The Product Backlog Refinement
Product Backlog refinement is the responsibility of the Scrum team and provides details, estimates and ordering to Product Backlog items. Product Backlog Refinement belongs to the family of events but is considered to be an activity rather than an event. This is because its format, frequency and duration may vary as needed and the refinement needs to happen on an ongoing basis. These characteristics belong to an activity, not to an event.
|My goals with this article were threefold: