One of the most important things an agile project management system can do is answer one simple question: when will this work complete?
There are a ton of project management tools out there in the world; but, most approaches still leave much to be desired when trying to answer this question.
Rather than surface the variability of the development process, these project management tools or issue tracking systems produce an instantaneous completion date. This doesn’t work for a variety of reasons, as we’ll get into below, which begs the question: If realistic schedules are the key to creating good software, what’s the solution for process improvement?
The prevailing idea that software development is a uniform, predictable process - that developer estimates are interchangeable, that you can plan Stories and Epics in isolation then roll up the results - couldn't be further from the truth.
Developer estimates (even of skilled estimators) are necessarily personal and cannot be translated to a developer with different skills and experience.
In addition, estimates do not translate directly to calendar time. You must take into account complex dependencies between multiple streams of work. Throw into the mix vacation, holidays, and sickness, on top of this variability in estimations.
It is too simplistic to think estimates can be rolled up and extended into the future from some start date arriving at a single date when work will complete.
The reality is: software development is better modeled as a stochastic process.
In the product development world, this means that planning done well should be global in scope, dynamic, aggregated, and its end result should be a date interval that approaches a single date as you approach the end of work.
Or, if you prefer, you could visualize it as a probability distribution: a sequence of dates each with a probability that it is the completion date.
How would this predictability change your business — if you knew with 95% certainty a project would complete on a particular date?
How would you talk to your customers about your Roadmap?
How would this planning process contribute to better coordinated marketing campaigns?
How would you prioritize features?
How many more sales could you make?
If planning was cheap and dynamic, imagine the what-ifs you could run. Imagine you could add more work to your Epic and see how it affects the completion interval, not just of that Epic, but of every Epic!
Imagine if you could grab the lower end of that completion interval, slide it backwards, and see highlighted the things you need to cut and the likelihood you can hit your new completion interval.
In 2007, Joel Spolsky wrote an article titled "Evidence Based Scheduling" where he laid out a process for using estimates, time tracking, and Monte Carlo simulation to produce a probability distribution for work completion. An evidence based scheduling feature was added to FogBugz and is still there.
“Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.” - Joel Spolsky
A similar concept is Earned Value Management. Earned Value Management has been around since the 1960's, has been turned into an ANSI standard, and is used in DoD and NASA projects. Earned Value Management tracks the planned cost and time versus the actual cost and time, and uses budget and schedule variance to predict where the project will land.
“Earned value management (EVM) is a project management methodology that integrates schedule, costs, and scope to measure project performance. Based on planned and actual values, EVM predicts the future and enables project managers to adjust accordingly.”
I submit these as an existence proof that the concept of continuous empirical planning is sound. I doubt that earned value management and evidence based scheduling are the last word.
In fact, there has been at least some follow up on how to generalize the idea of a continuously improving model for software estimation (c.f. "Optimization of Software Estimation Models").
Could this work using Shortcut? Well, what if you tracked the amount of time spent on a Story versus the time that had been planned for it? This would form a population of data points. These data points could be segmented by Story Owner, Project, and Epic, and each segment would get a statistical profile (something like mean and variance).
In a more general sense, when thinking about product roadmapping and continuous improvement, at Shortcut, we believe that each person’s work should be connected to transparent company initiatives, decisions, and the plans behind them.
Startups try to make this happen with OKRs and other quarterly planning methods, but do you know of a single software engineer (or other team member) who is happy to be going over OKRs? Most people simply tolerate it because they’re at a job and are being paid money, which, to be fair, is a reasonable trade.
But if you want to do great work, you need to put your employees in a position to do more than tolerate what you’re asking of them.
Whenever and wherever you can, when an employee— product owner, scrum master, individual contributor, anyone— finishes some part of their work the act of completing it should automatically update the goals for them and clearly show them how much progress is being made so that they’re not scrambling to update a spreadsheet 30 minutes before their weekly squad or sprint planning meeting.
At Shortcut, we’re always thinking about software project management best practices, and how we can translate that into our product. Thinking about agile practices, agile teams, agile frameworks, agile methods, and continuous empirical processes = just the tip of the iceberg. To join the conversation, check out our Discord. We talk about other stuff there, too - don’t worry.