Scrum thoughts: staggering sprint teams

October 16, 2007. Series [ Scrum Thoughts ] Tags [ prototype, Scrum, sprint, waterfall ]

When you have two or more sprint teams dedicated to a product, I think there’s an opportunity to stagger their efforts in the following way. Let’s track a user story through two sprints. In the first sprint, the prototyping sprint, design, UX, and development cooperate to put together a working proposal for a user story. At the sprint review, if possible, the whole user story will be complete, where design, UX, and implementation are all consistent.

This is very important, because one of weaknesses of the traditional waterfall method is that design, UX, and implementation must be consistent before the software is finished. Obviously, the implementation will be influenced by the design and wireframes, the wireframes will be influenced by what is visually possible on the page, the design will be influenced by the functionality required by the wireframes, the design will be influenced by what is hard or easy to realize in HTML/CSS, the wireframes and functionality will be influenced by what is feasible to build in the backend (whether from an LOE standpoint or from a performance point of view). The waterfall method doesn’t allow for the full richness of this interaction to help arrive at the “optimal” way to solve a user story from all points of view.

However, if we are considering features where we want more lead time than a month, then it may not be possible to get all the way to a finished feature in one sprint. Instead, it may be enough to get to a consistent prototype, where there are designs, wireframes, and mostly-working code that can be shown at the review. All of the creative output may not be integrated yet, but it should be close enough to know that it can be gotten to a consistent state.

This is where the next sprint comes into play: the finishing sprint, where the mockups are brought to production by the same team. Naturally, they will take product owner feedback from the review into consideration during the finishing sprint.

In the simplest case, let’s say we have two scrum teams. We can stagger their sprints such that when one team is in the prototyping sprint, the other is in the finishing sprint; this way we’re still able to release new functionality to production after every sprint while still enabling cross-functional development of larger features.

However, we can actually take things a step further: if, during pre-planning, we can roughly separate the stories into “small” (can be taken from start to finish in one sprint) and “large” stories, then we can actually mix things out in interesting ways, like:

Here:

• SF : finishing sprint for small user stories
• LP : prototyping sprint for large user stories
• LF : finishing sprint for large user stories

So here we have Team 1 kept full with small user stories every sprint. Teams 2 and 3 are kept full with large user stories, but staggered (note how Team 3 starts with a small finishing sprint so they have something to do during Sprint 1!). Then Team 4 operates under a model where some of their user stories are small, and some are large.

I think the only operational trickiness here, from a software development standpoint, is that any “LP” work needs to happen in a branch and not the main development trunk, because it will not be production-ready by the end of the sprint. When the product owners finally sign off on an LP prototype as being ready (it’s always possible that the product owners will not like–or will require significant enough changes to–a user story solution, thus requiring a follow-on LP sprint), then the first task of the LF sprint would be to port the branch back into the trunk and continue on.