on testing. They were able to deploy the maintenance release one sprint later and resume work on the new feature the following sprint.
Figure 3: Snapshot of the PMO online dashboard that gives status on all agile projects as well as the story points required to achieve each release, and each team’s progress against each release (story points per iteration = velocity)
Ultimately, these dashboards gave visibility to the overall Value Stream by showing business initiative release plans that used velocity (story points completed each sprint) to predict release opportunities. As teams matured and velocities began to converge, budget spent (simply the burn-rate of the team) was shown against prioritized features. This powerful chart helped focus business stakeholders on respecting the managed queues of work and only feeding in high value project requests into the pipeline. When teams were put in a state of thrashing because of multiple stakeholders not working together to prioritize their work, budget spent would bubble up as applied to lower priority items, and quickly bring awareness that organizational capacity was being spent against lower priority work.
Figure 4: Feature profile chart. With all the information now available through the standardized use of features, estimation using story points, and velocity, detailed analysis charts can show cost of story points required for minimal release, and incremental ROI.
Bringing it together (Case Studies)
Below are descriptions and outcomes from four programs that were involved in the Lean-Agile transition. Their challenges and outcomes are common patterns observed when organizations are committed to trusting the principles and commit to improvement.
Supply Chain Product - Long Release Trains to Sprints and Incremental Releases
This team had been suffering from the 'long release train' approach and multiple stakeholders with differing priorities. It was one big long list of scope trying to make the next train since they knew there wouldn't be another train for 12+ months. The classic 'holding all scope hostage' until the last item was done regardless of priority. The product owners quickly aligned to one prioritized list because they knew the team would have something deployment ready as quickly as possible due to clear focus.This product had strong technical leadership and development team maturitywhen it was selected for the pilot, but they really knocked the ball out of the park quickly as they embraced the new Lean-Agile principles.The team delivered four releases in the first ten months of using Lean-Agile!
Field Force Product - Stakeholder delight
This project was a neat success story for a few reasons. First, it was a project newly underway in development, and it was somewhat of a surprise request (with a fixed date) from a key Business stakeholder to replace an existing tool created by resources outside of IT. After seeing the early Supply Chain Product successes, the Development team thought this would be a perfect project to transition to Lean-Agile given the aggressive timeline. So, the team attended the next training session where they were able to create a product backlog and their first sprint plan. Then this team was off to the races on delivering incrementally demonstrable work to the Product Owner. After the first demo, the product owner quickly realized that he had not done a good job of defining requirements and they were venturing down the wrong path for the solution. Why is this a neat success story then? Because the team and the product owner figured this out on Day 10 and were able to correct themselves, getting better sprint after sprint. The product was 'right on the money' when it was deployed and this product owner