LinkedIn principal author Doug Winnie describes how work with product sprints to make modifications and tweaks to your product lifecycle to change and adapt to market, company or team demands or needs. This includes shortening or lengthening phases, or overlapping sprints on top of each other to create a more compressed schedule.
- Starting with a sprint gives you a picture of how a single iteration of your product development will work. The next step is to create additional sprints and see how they interleave with each other and stack up against the resources you have for your product and team. Here are some ways to apply multiple sprints and find out how to mitigate issues that you might find. If we look at our single sprint, we know that this is just one version. We need to start looking ahead to the next release. Agile helps us overlap and stack releases together.
So what we learn from one release can flow into the work for the next one. For consecutive releases, we don't need a full four weeks of research. Of course, you might decide to do a full research plan with you team at a later point. But for consecutive releases, we can reduce that to two weeks. We can then overlap that with the later half of the build phase for the previous release. So in this case, we have the research phase for the second release to start on February 19th, or eight weeks in.
We can then overlap the release and plan phases, and then start building for another four weeks. For the second release, we won't have the benefit of refined data we'll get, but we'll undoubtedly have features or work that we couldn't fit into the first release and can flow into the second. But at the third release, starting in the thirteenth week on March 25th. We can take the information we learned from the refining phase of the first release and flow that into the research phase for the third version.
From this point we have a good rhythm and cycle that we can continue build and by the sixth release we can go to customers the week of September 23rd, 39 weeks since you started. But then we look and decide we really want to have that release get to people faster. Through our early research, we have found that casual games have their peak usage during the summer. The great thing with schedules is that you can tweak them and model them differently to see how different scenarios work.
Frequently, Agile project teams work in shorter sprints, perhaps only dedicating two weeks for the build phase. If that is the case, you could model it differently to fit within your timeline You could reduce the build phase to two weeks. And shift everything over. In this case, you can ops to overlap the refine phase for one release with the research phase for another. Now, I have the 1.0 release hitting the apps store the week of June 3rd, just in time for the summer. But when you meet with your team, they're feeling uncomfortable getting all their work done with two week sprints.
In that case you can shift things up, you could have the phases of the releases not overlap as much, and having everyone dedicated to focusing on the first initial release. You can then determine that you will build the first public version with fewer features and add them in subsequent releases. The game will then come to the app store on June 24th still in the early part of the summer and then can add two subsequent public releases. Scheduling is just as much of an art as it is a science.
The schedule that we are talking about is absent of any actual work. Although, plans are great. They need to react to the work that needs to happen. As the product manager, you are the leader who will collaborate with your team to determine what timeline is the best for you, your team, and ultimately, for your customers.
- Types of products and industries
- Leading through influence
- Understanding your team
- Using an agile or waterfall development cycle
- Managing your product life cycle
- Researching your market, customers, and ideas
- Planning the product
- Building the product
- Releasing the product
- Refining the product
- Understanding when it's time to retire the product