The Inception Sessions
For this initiative, the Inception lasted 10 day, which was approximately 10% of the overall project time frame. It helped the team to form around the project, and focused on delivering the right things at the right time. This gave a shared sense of purpose and allows them to adapt to priority changes from the Product Owner as they gained more understanding.
Inception took the format of a series of workshops, where the team members converged and diverged around tasks to get a shared understanding of the work.
Rather than using a traditional requirements elicitation to break down the project into a requirements backlog, the team used a mindmap to rapidly understand what is needed and how the requirements relate to each other.
By focusing on the mid level requirements (Epics) we we confident that we had the project scope covered. We were also able to insert candidate User Stories under the Epics to help us estimate them.
This was the team is able to work in a “Just in Time” way, undertaking a more detailed analysis on the Epics as they are about to be fed into the delivery pipeline.
Enhanced Cost & Benefit
During inception we also refined our cost / benefit estimates. By focusing on the day rates of the individual squad members, and the refined project duration (see the delivery plan below) we were able to refine our estimates from a Rough Order of Magnitude to a mid level of accuracy.
To compliment this we also reviewed our expected benefits and realised the large benefits associated with upsell.
For this initiative we realised that the cost of delivery would go up as the team would take longer (7 months rather than the 5 months we estimated in discovery) to deliver the scope. This was offset by the £3.8m benefits estimation – an increase from the Discovery estimate of £1m
Our Epic Board Delivery Plan
Once we had created a backlog using the mindmap, it was really easy to estimate. We stack ranked the Epics into a prioritised list showing how we expected to deliver them and then estimated each against Size (T-Shirt Size) and Complexity (Low, Medium and High).
The Epics were colour coded (Blue represents Tech work, Yellow customer features) and we overlaid monthly timeboxes to provide capacity limits and then simply built our delivery plan.
The final task was to identify our release points. Dependencies were added to the board to cover the release of the Epics we planned to deliver that month.
Our Release Proposition
Building on our Epic Board, we also created a Release Plan to highlight what we want to ship and when we expect it to go.
This way we are able to focus on the business readiness that is needed for each release. This helps us with release efficiency as we’re able to assign timescales to the business process changes we identified.
What we've learnt doing this...
Release Propositions allow the team to focus conversations on where the deminishing returns start for the product. For example is the content in Release 3 in this project going to provide lower value than the next project that has just cleared Discovery.
The final artefact in the Inception deck is the projected benefits graph. This graph expands on the release proposition and helps the team visualise that as we are releasing incrementally we will be expecting to get some returns early.
This is key as it aligns to both expected benefits and KPIs for the project. This will link into the team metrics and reporting within the delivery stage, with the team constantly monitoring progress against value delivered.