Working in agile on a product means you have to be ready for change at any time. Your product vision is a guiding light which sets the direction of where you’re going. But how you get there and what you encounter after every turn or hill on the road still stays pretty much a mystery until you're a few steps away from it.
Having a plan in advance is still a must. But ensuring that it’s flexible enough is equally important.
We’re going to show you how a backlog and priorities can change within an agile project from an initial idea to something completely different at the end within several months.
State 1: Clear Phases of Delivery
In serving a recent client, we are able to display how the variability of Agile works. In order to keep their IP in their hands, we will describe and display, but without specifics. Before the development even started there was a vision of the product and a roadmap describing how we were going to approach it. On a high level there were several epics with multiple specific features listed as requirements.
In line with the business priorities, development had been split into two phases.
- Phase One contained several business-critical features that would form a marketable product. It was planned for about 7 months.
- Phase two for another 3 months saw extended versions of these features, several large focus areas, and external integrations.
The main goal of the separation was to concentrate around more or less known features and data, make a big public release, and continue with the vision in additional phases.
The original roadmap resembled this:
Phase 1
Phase 2
Disclaimer: features are actually not the same size. Some might be quick to be done in less than a sprint, some others can take more than 1 sprint. So they were split into several smaller pieces.
State 2: Reaction to Change and Redesign of Phase 2
As the project advanced 3 months, with the first phase in implementation, it became clear that one of the key external integrations was not going to be possible. At least not within the timeframe of the plan definition of Phase 2. Other parties who were set for integration were not technically ready. So, we cut some of the bigger features from the scope and compiled a waiting list.
The roadmap took a new shape:
In the above, the lighter-shaded blocks represent features that were removed from the scope.
State 3: Another New Vision Realized after Phase 1
By the time the first phase finished, the vision had changed, of course. The change was expected, but one never knows in advance in what direction/s the projects will take.
During Phase 1 we were gradually rolling out features to the public and onboarding small amounts of users after each small release. Once the critical mass of features was reached, we made a bigger public announcement and launched marketing campaigns to attract more users.
There was excitement about the product and we received feedback about existing functionalities. In turn, we dedicated a larger buffer for updates to current features in Phase 2.
Besides that, new ideas were considered important enough to be added to the scope.
In parallel, an important feature was integrated into the scope by a stakeholder. The vision was to set the existing team to work on integrating with them rather than redesigning and implementing from a new beginning. This was to have simplified the implementation.
Thus ending Phase 1, prior beginning Phase 2, the roadmap took a quite different look than initially:
Disclaimer: Green above represents new and added features.
State 4: The State of Things After Phase 2
Phase 2 was planned for a shorter period of time, circa 3 months, against 7 months for Phase 1.
We found the changes to the scope and priorities during this period were more dynamic:
- Conversion of registered to paid users (including some marketing activities) was realized as more important than expanding features.
- Deprioritization of some new features in favor of others
- Improvements to existing features were found to be needed, resulting in time allocation to these changes.
- Integration of third-party systems was deemed impossible for the client/business with technical problems on their part, and thus removed from the scope.
- Development of the main API slowed, thus more planned features were deprioritized.
After all the changes, the scope of Delivery had many differences from the original plans:
…and keeping only that which was implemented:
As a result, only one major new feature from the original vision was implemented in Phase 2. All of the remaining development in Phase 2 were based on features implemented in Phase 1 (improvements/extensions based on feedback and analysis) and a completely new scope.
Epilogue
So expecting the unexpected, only the size of the changes is unknown when you begin. Even with a stable product, vision priorities can become very different from one month (or even a week) to another. Tracking these changes, will lead to later reflection and the embracing of them in other phases of your projects and even future projects.
At Jimmy we don't just “think we’re Agile” we are. Let us help you with the full Delivery of your next software project, as leads (Delivery Management, Design, and/or Product Owner), or as augmentation to your existing team with specialized talents or additional resources to get through your Sprints.
Reach out for more information.
Nikita Lamonov, product owner
