A deeper understanding on…
Empiricism: Inspection, Part Two
Road to PSM III — Episode 3.2
[revised for 2020 Scrum Guide update]
Inspection revolves around comparing the current state with the desired state.
During the Sprint, developers inspect the progress of Product Backlog items toward the Definition of Done. When the item is Done, an increment is born. Developers then inspect these increments as progress toward the Sprint Goal. During the Sprint Review, they inspect how the latest increments result in outcomes that are indicators of progress toward the Product Goal.
Approaching inspection with Scrum is highly contextual. In this appendix, I’ll deep-dive into how an inspection can be done based on my own experience.
Here is some input that might help your team inspect in context to software development:
Inspecting progress toward the Product Goal.
During the Sprint Review, the latest increment and the outcomes of the Sprint are inspected together with stakeholders as progress toward the Product Goal.
Inspections on how actual users experience the product can also be called validations. Everything up to the point of delivery has merely been a value assumption or hypothesis. The story doesn’t end. It's only after delivery that a Scrum Team can learn how it is actually of value.
The Sprint Review is an opportunity to discuss the input collected on how the marketplace or potential product use might have changed.
Professional Scrum Teams apply Evidence-Based Management. They can inspect the current increment, current value, and unrealized value by measuring Satisfaction and Usage, Market Share, and Satisfaction Gaps.
Such insights can be collected anytime during the Sprint. This can be done in many ways, depending on the context, but common approaches for digital software productions are:
- Product use analytics — like (returning) visits, click-throughs, time spent, drop rate, conversion funnels, and rates.
- A/B testing — is a common approach to get test results from the actual usage of various approaches to see what works best.
- Heatmaps — what is drawing and retaining the customer's attention?
- Recordings — actual recordings of user interaction sessions, maybe enriched with audio/video where the user talks about what is experienced.
- Surveys and interviews — ask direct questions to get a deeper understanding of the user’s experience and needs.
- Service Safari — recordings on experiencing the product in the field.
With this, and with the feedback collected on the delivered Increment, the whole group (Scrum Team + Stakeholders) will prepare valuable input to subsequent Sprint Planning.
Inspecting the Definition of Done
Almost done is not done.
Through the Definition of Done, everyone shares the same understanding of what makes the work on a Product Backlog item complete.
Some Definitions may include automated practices supporting Continuous Integration, such as creating test scripts to automate builds.
I encountered developers who didn’t seem to think testing or inspection was a part of their job. They considered themselves programmers. In this case, I explained that being programmers, they could program tests. It is their accountability as professionals to ensure quality. In Scrum, they are also no longer just programmers. They are product developers, accountable for delivering value, not just code, to stakeholders. That means their accountabilities and responsibilities may need to be revisited.
In software engineering and web development, it’s common to perform Pull Requests and engage in Code Reviews or Pair Programming, during which the following could be checked:
- Check if logging and monitoring are applied.
- Check if exceptions are applied (unhappy flows/exception handling).
- Check if unit tests and integration tests are applied.
- Check if the results of a performance test are acceptable.
- Check if the release notes are clear and complete.
- Check if the code is clean and understandable.
- Check if the Boy Scout Rule is applied (Always leave the code cleaner than how you found it).
- Check if it functions like how you think it was intended for the user.
- List potential improvements for the next iteration.
- Check if the Responsive Behaviour aligns with supported browsers, devices, and breakpoints.
Another benefit of this approach is that it promotes continuous learning.
Inspecting the Product Backlog
The Product Backlog is inspected to determine if items are clearly ordered and understood, how they are to be of value to Stakeholders, such as how they contribute to the Product Goal.
“Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.” — The Scrum Guide.
So if the answer from the Development Team is “yes” to: “do you think it can be done within the Sprint?”, that should suffice.
Watch out. I recommend you do not extend the Definition of ready beyond what the Scrum Team deems is needed to be confident it can be done within a Sprint. Exhaustive “Definitions of Ready” will block your flow and allow habits of Waterfall to impede empiricism.
Nebulous PBIs
If the PBIs are not concrete:
- The introduced uncertainty about how items will be of value will reduce the team’s ability to satisfy stakeholders.
- The Scrum Team might not fully be able to demonstrate Sprint’s value to stakeholders by the Sprint Review.
- The Developers might be unable to align on the work that needs to be done.
- It is possible that, due to the lack of proper understanding of the value of the PBI, the Developers may be unable to design the best approach, allowing waste to incur.
- The team might encounter unexpected challenges which impact the forecast, and the team’s ability to produce “done” increments.
- Technical Debt will come back to haunt the team as the team may not have considered some essential scenarios.
This overall could make the team less predictable and the product less valuable.
That said, even during the Sprint, the Product Owner and Developers can
- Self-organize to develop a better understanding of the PBI.
- If work turns out to be different than expected, Developers may renegotiate the scope in the Sprint Backlog together with the Product Owner, whilst remaining committed to the Sprint Goal.
Inspecting progress toward the Sprint Goal
During the Sprint, the Developers frequently inspect the progress made toward the Sprint Goal.
Daily Scrum
During a Daily Scrum, the Developers inspect how progress is trending toward the Sprint Goal. This is generally made transparent on the Sprint Backlog, where a certain flow of work is made visible. Kanban is a great approach to enable teams to work out the flow.
Download the KanBan Guide for Scrum Teams here.
Significant aspects of the process must be visible to those responsible for the outcome and value. Therefore, the Scrum Team and its stakeholders must be open about all the work and the challenges.
Developers may choose to invite observers for this purpose or involve them immediately after the Daily Scrum. Note that observers do not participate. During a Daily Scrum, the developers must be as technical as necessary. Observers may only be invited by the Developers and only if this benefits transparency and inspection.
Inspecting the Scrum Team itself
Pfew! almost there.
Now, inspecting oneself is perhaps the hardest.
The vast majority of organizations, when confronted by a mirror, are not pleased by what is shown. Nor should they.
“Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.” — The Scrum Guide
When events are canceled or postponed, time-boxes not honored, goals not set, Definitions of Done dismissed, accountabilities ignored, values not embodied, quality not ensured, and so on, I can bet that the potential to deliver value and develop trust is ultimately diminished.
The framework itself is never the source of the issue.
Scrum either succeeds or fails with professionalism.
For example: When a team hasn’t delivered in Increment that is done by the end of the sprint, it’s not the Sprint’s time-box that causes this.
The Scrum Team will have to inspect itself. This means members should be courageous to coach and support each other to improve respectfully.
During a Retrospective, a team may inspect how people, relationships, events, processes, tools, and the Definitions of Done can be optimized to increase trust and value. The team collectively creates an improvement plan that is used as input for the next Sprint Planning.
Here are some formats that I have used that can help teams reflect and inspect itself:
- DISC
This assessment could be used to make behavioral differences transparent and promote discussions to benefit team forming and alignment. Team members may exchange why they agree or disagree on certain test outcomes. Do others recognize certain behavioral patterns you didn’t? - SWOT
A powerful brainstorm where members share and discuss strengths, weaknesses, opportunities, and threats. This can be applied to the product, PBIs, the team as a whole, or the individual. - Team Canvas
Creating a Team Canvas is an essential exercise to help teams get on the same page. Team Canvas | Athletic Team Canvas - Personal Map
This a great way to enable team members to get to know each other on a more personal level. One way to approach it is to challenge members to fill in the maps of other team members. Management 3.0 | Athletic Development - Glows and Grows
Positive feedback helps us grow. Giving effective feedback is a competence. Sometimes individuals may find it difficult and uncomfortable. Glow and Grow prompts team members to provide and receive positive and constructive feedback.
So that brings us to the end of the EPIC two-part episode on one of Scrum’s most fundamental pillars: Inspection.
The Road to PSM III is being updated to the 2020 edition of the Scrum Guide and new standards for PSM III assessment.
Join the Road 2 Mastery
