On the Mingle team, we’re constantly thinking about how to advance our thinking on software delivery. That’s one of the reasons why we’re excited about aligning ourselves more closely with ThoughtWorks’ views on software excellence.
Part of this process involves thinking about how our products reflect our values. We value, among other things, collaboration and transparency, so we try to build products that promote conversations and improve visibility.
Two of the more common conversations we hear practitioners having center around the questions:
- When will we be done?
- What can we get done by date x?
The Mingle team has recently developed the forecasting and fixed-date charts to help foster productive discussions around answering these questions. We’d like to share some insight into their development below and welcome you to try them out in Mingle 12.1.
The Forecasting Chart: When will we be done?
To help answer questions related to forecasting, we took some cues from the work of James Shore and others on schedule projections. Mingle’s new forecast chart addresses how delivery dates may be affected by one of the more common forms of schedule risk: increases in remaining scope. “How?” you ask. Well, here you go:
The forecast chart shows when your team may deliver--based on your definition of “done”--in relation to changes (0%, 50% or 150%) in remaining scope[1].
In developing this macro, we made some simplifying assumptions, especially concerning velocity. We do not consider variability in velocity and sources of that variability (e.g. technical debt, customer availability, sick days). Instead, we use a constant average actual velocity to date.
The resultant chart is intended to prompt a conversation. Decisions around how much we think scope will increase, and therefore projections about when we may be done, are still left up to the those best equipped to make them: the delivery team.
The Fixed-Date Chart: What can we get done by date x?
So far, we’ve looked at how changes in remaining work impact our schedule. But what about when our delivery date is fixed and we have to communicate that some features won’t make the cut?
The fixed date chart is intended to signal when we may not deliver everything we planned by a given date. When the actual velocity (again, average velocity to date) is estimated to create a burn-up that falls short of total scope, team members can have a conversation about which features are ready to be delivered and which may have to be left undelivered.
How we use forecasting and fixed-date charts
We’re already using both the forecasting and fixed-date charts on the Mingle team. The charts were easy to generate since they use data already being captured.
For example, as we were dog-fooding these new charts for our 12.1 release, the forecasting chart was projecting a release date range between the end of April for no scope change and the end of May for a 50% increase in remaining scope. Given our preference to release in early May, we used the fixed date chart to gauge how many stories may not have been done by our preferred target date. The chart helped focus our conversations around prioritizing remaining stories and removing non-essential work while still leaving us with what we felt was a cohesive product.
We’re always interested in learning more about different ways we can use tools to inform our decisions and affect the way we collaborate with others. What do you use to start conversations about constraints on your project?
Thanks, and more soon from the Mingle team.
[1] We’ll talk more about the rational behind these numbers in a follow-up post.