Kickoff-review-approve — a simple take on knowledge sharing and collaboration in the Scrum Team

When I work with Scrum Teams an area that often is overlooked or causes difficulty, is the collaboration within the Scrum Team that happens after a development team member picks a new Product Backlog Item (PBI) from the Sprint Backlog. The actual work of implementing the item is done alone, and in parallel with the other Development Team Members, who are also working on their own backlog items — alone…

This is of course very generalizing and simplified, and most teams have some variety of collaboration going on when coding. And after all, we talk about what we are working on at the Daily Scrum event, don’t we?

Sooner or later in the life of a Scrum Team, some or all of the following questions arise during a Sprint or in the Sprint Retrospective:

• How do we share knowledge better when developing?
• What is an appropriate level of testing?
• How do we ensure the quality of the code and product?
• When is a given PBI done?
  ‍

In my experience all too often we try to create a common template or approach to addressing these areas, but often the answer depends on the individual PBI.

My suggestion often boils down to the following 5 steps: Kickoff, Development, Development Review, Approval, Release.

The steps are a way to keep it simple, and to get the benefits of collaborating with the rest of the team to avoid building the wrong thing or building it wrong. It enhances the knowledge sharing internal in the Development Team, and between the Development Team and the Product Owner.

The practical steps

Kickoff

My suggestion is simple. The developer kicks off the work on a new backlog item in a series of short sessions with the following people:

• The Product Owner. The purpose of this session is to make sure the desired outcome of the PBI is understood, and clarifications about the product change can be done
• A peer developer who will also review the code when done. The purpose of the session is to talk through areas such as code structure/architecture, level of automated tests, areas of special attention, etc. This way the reviewer and developer have shared knowledge and put down the foundation of the implementation and coming review. If more than one developer is known to be working on implementing the PBI, this will of course be a joint session with all those developers.
• QA. How will the feature be tested? How can accept criteria be validated? What are the critical areas to be tested, and how is the testing effort prioritized.

Development

With the implementation strategy clarified with a peer developer, this is where the actual code is written, and the feature implemented. A lot can be written on all the practices relevant in this step regarding software craftsmanship and technical excellence. I’ll leave it out of the scope of this post.

Development Review

The developer and the peer developer reviewer get together to review the implemented code according to what was agreed in the kickoff session.

Approval

The developer(s) and Product Owner get together to review the PBI to make sure the implementation meets the requirements and acceptance criteria. This would also be a good time to include the QA competencies on the team.
When to release the feature is up to the Product Owner.
Depending on the maturity of the team and release infrastructure the actual release can be immediately after approval, at the end of the Sprint, or maybe at a scheduled release later.

Repeat

Consider the above steps as a recipe for inspiration. It’s a simple structure to start with for getting more collaboration into your team. As with any structure or framework, it’s what’s being done within the framework that matters. Experiment, inspect and adapt to get closer to a way of working that fits your team.

‍

Curious about agile? Never miss a post!
Sign up for our newsletter (in Danish) right here 👉🏻 syndicate.dk/backstage

‍