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:
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.
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:
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.
The developer and the peer developer reviewer get together to review the implemented code according to what was agreed in the kickoff session.
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.
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