A week is a long time in politics— Two weeks can be longer in Product Development

Scrum guide is outdated in many ways but the traditional way of doing a Sprint Review does not work anymore. The main reason for a Sprint Review is to elicit feedback. Most teams run a two-week Sprint and a two-week feedback loop is too long given the current development capabilities of most teams. Many teams are realizing this and changing Sprint length to one week. Even a week can be a long time in product development.

Imagine a team of 3–4 devs, a QA, a BA/PO and Scrum Master working on a product. In a week's time, a lot of features that can be developed. In addition, budget burn-down will be significant. You can spend 20–30K from the budget before you have a chance to elicit feedback from your stakeholders. This is the best-case scenario assuming you are running one week Sprint. On a two week Sprint, the cost will be high. The snowball effect of this process at the end of product development will be quite significant in terms of cost and the quality of the end product.

Solution: Cut the feedback loop from weeks to days

Our team has come up with an approach to cut the feedback loop from two weeks (as initially was the case) to two days while still running a two-week Sprint. A two-week Sprint still works best from a Scrum logistics purpose (Planning/Retro etc) however, we have customized a few aspects of Scrum to make it better for us. We have done this using the following approach

One: Specific User Stories Grooming Sessions

We run small timeboxed user stories grooming sessions with clients and the Scrum team. We deliberately limit the session to a maximum of two large user stories to be able to focus on the features that need to be delivered in the next couple of weeks. This helps develop a good understanding of what needs to be built.

Two: Smaller Planning Sessions

We run the planning session to focus only on one or two large user stories. As the grooming has already been done and the team now has a good understanding of the features to be built, it takes less time in planning. The team then splits the user stories into ‘Vertical Slices’ — end to end implementation of a small part of the feature that delivers value and is testable. The rule for a vertical slice is that it follows the I.N.V.E.S.T principle and can be developed in 2 days.

Three: Open Stakeholder Standups

We set up an online stakeholder standup every 2 days. Anyone interested in the project can join along with some key stakeholders. As we will develop a small independent, valuable feature slice in 2 days we show the progress of working software to the stakeholder group. This creates an immediate feedback loop and keeps the stakeholders excited and engaged in the development process. It is a live view of the product being built.

Four: Deliver Working Software early and often

Deliver the complete working feature as soon as you can in the hands of your customers and stakeholders. Do it early and do it often. This can be from 1 week to a 2-week cycle. Nothing will elicit more feedback than the users actually using the product.

Word Of Caution

Delivering small meaningful work within a two-day cycle requires a high level of capability and discipline from your team. It also puts pressure on your stakeholders. Your stakeholders will have their day jobs and committing time every 2 days will be hard. It will also add the extra pressure of reviewing the progress of product build every 2 days and provide feedback. Most of the people will feel stretched if not overwhelmed.

Carefully design a strategy to help your team and stakeholders go through this process. Some strategies that we have employed

• Split the stories that will provide meaningful work but can be completed in 2 days
• Timebox the stakeholder stand up to 15 mins. Enforce it
• Provide continuous support and coaching to your team and stakeholders.
• Always inspect and adapt
• Follow Kanban principles to improve the flow

With the above changes in our process and more customer and stakeholder engagement, we are now building better products with a much higher level of customer satisfaction.

What do you think? I will greatly value your feedback and comments on this article or regarding your own experience.