Are we really 15 years into Agile and still failing to master one of the foundational principles? That is to use data to provide frequent, actionable feedback loops. Most teams still rely on the most rudimentary of metrics… velocity and burndowns.
We know we can only deal with the complexity of software development by using, ‘inspect and adapt’ cycles. We have collected lakes of data in every TFS, Jira and Rally instance and yet most of it remains as clear and useful as a stagnant pond.
Metrics are tainted by years of association with ‘governance’ and of being used to feed the ‘process Gods’. The idea that the individuals within teams might actually benefit from this insight seems to have been overlooked.
SenseAdapt is a collection of simple visualisations that enable teams and stakeholders to sense what is going on in their system and adapt it, in order to deliver more value.
Our aim with SenseAdapt is to bring objectivity and help create a shared, common understanding of what is going on. The conscious and sub-conscious motivations of team members, project managers and stakeholders too often clouds the picture.
The visuals are being used by three of our largest clients and continue to evolve rapidly with their feedback.
Data-based, Actionable Insight
- Data-based
- We utilise the data that teams are already collecting. Although, now that that data benefits them, there is more reason for them to care about its quality
- Actionable
- Just one click away, or on a dashboard, and displaying the real-time data
- Insight
- Simple, comprehensible visual representations
- Relevant as it shows how the system is behaving right now, not just retrospectively
Note: SenseAdapt continues to evolve. Please get in touch if you would like a demo or join our other clients in trying it on site. For the moment it is free – in exchange for your feedback.
Team-Facing Visuals
Used through the day, possibly in a dashboard, and draw attention to the parts of the system that need action. For example; PBIs (Product Backlog Items / user stories) that have got stuck or forgotten, the levels of WIP per person, the number of unestimated or PBIs that are too big.
The visuals also provide useful input into the retrospectives.
WIP by person
Highlights who is overburdened in the team and therefore needs to complete a few items of work – rather than continue to start new items.. i.e. adopt the ‘Stop starting, start finishing’ mantra. Could be used at the daily stand-up
Cumulative Flow Diagram (CFD)
Shows the behaviour of the system over time, the bottlenecks, levels of WIP and lead times.
Requirements readiness
Draws attention to the PBIs that need to be refined, sliced smaller or estimated. The chart shows the numbers of PBIs of each size, and their state. It clearly shows the unestimated stories as well.
Sprint (Iteration) burndown
This is better than the commonly used sprint burndown, as it shows the rate that the team is actually completing stories – not just tasks.
This example shows a typical anti-pattern of last minute closing of stories in a sprint. The story burndown, in points, is shown on the right hand scale, with task burndown on the left.
The use of live data means that this chart can show an ‘intraday’ burndown
Backlog health
Shows whether PBIs are in the correct Iteration Path or Area Path (when using TFS).
Most metrics are driven from the Iteration path, therefore PBIs in the wrong iteration can lead to a misleading picture and incorrect forecasts.
This is toggle-able between Iteration paths (above) and area paths (below)
PBI Staleness
Teams quite often come to overlook PBIs, which may stall in a particular state or just be forgotten, this particularly the case if there is a lot of WIP (Work in Progress).
This chart draws their attention to PBIs that have not been amended for and need some attention.
Business-Facing Visuals
These charts help stakeholders understand where the project is and when or what options there are for intervention.
Live project data – one click away. Each saved chart has its own URL that can be emailed or held in a project page or wiki.
They help to keep stakeholder expectations realistic and aligned. Significantly more informative and transparent that opaque RAG updates, which hide as much as they reveal and remain largely subjective.
Burn-up / Landing Zone
The burn-up clearly shows the range of likely delivery dates of a project. The example below is from a client with two teams totalling 20 people.
The project is likely (we deal in probabilities) to land in the shaded green ‘landing zone’. It’s clear, in this example, that one of the key risks to the delivery date is the rate of increase of the scope.
o 
This forecasting is based on standard deviations from the mean , which can be varied by the user, using more or less history in the calculation of the mean and choosing how many standard deviations for the forecast.
Most teams have settled for burndowns and velocities which offer far less insight and awareness of possibilities. See my other post for more on the Landing Zone
In the near future we will use Monte Carlo (see below) simulation to model and forecast both the scope and the throughput rates.
Feature Progress
Shows the progress of PBIs within a feature. Business stakeholders can clearly see the relative size of features, as well as the progress.
Release Treemap
Shows the status and relative size of all features. Clicking on any feature will show the same for its child PBIs. Features and PBIs can be opened directly in TFS.
Simulating the future
Thought leaders, like Troy Magennis, toil on the edge of our Agile consciousness, promoting ideas that we should all have embraced in a heartbeat – specifically that the data of how our systems have behaved to date is the best predictor of how our systems will behave in the future.
His website and blog Focused Objective makes a very strong case for this approach.
Essentially, if you want to predict when a project is likely to land, you need to:
- Create a mathematical model of how your system, whether a single team or a programme, has been behaving historically, based on the actual data
- Then take the remainder of your backlog and run it through that model thousands of times, giving you a frequency distribution of the possible dates it could finish.
- Use that range of dates to engage stakeholders and start discussions about what could be done to land the project successfully.
After 10,000 runs the output looks something like this.
We will write more extensively about the use of simulation within SenseAdapt in later blogs.
.