I will describe how maturing Agile projects can actually provide more transparency into the current project status and estimates with higher confidence levels than those typically used in traditional project planning. I will call this “Predictive Agility”. I will focus more on Scrum but the same principles apply to other Agile methodologies like Kanban.
Many executive and managers who are considering adopting Agile have the misconception that Agile projects do not have the ability to give an estimate of when a product release will be ready for launch. In their roles, they need to communicate the status and projections of new products to potential customers, stakeholders, and business shareholders. In some cases, a product must have new features and be ready by a certain date or else there is no reason to start the project. They have the impression that there is a conflict between adaptability and predictability.
The misconception is a result of many in the Agile community who have focused on the principle “inspect and adapt”. I have seen several projects where Agile team members tell management that they can not give an estimate because Agile development encourages change at every short iteration. 
Yes, but the change is transparent by looking at the Product Backlog (or Kanban board). You can see what we have completed and how much is left to accomplish. We can calculate an average velocity, that is, the amount of work we are completing on average in each time boxed iteration. From this we can do some quick statistical projections of worse case and best case projections or where we will be by a certain date or iteration.
If you are new to this topic, a good starting point would be to view Product Owner in a Nutshell by Henrik Kniberg. The video gives some basic knowledge about Agile and near the end talks about project estimation with best and worse case estimation.
Here are three keys to reaching predictive agility:
Transparency is key. When change is proposed, it is important to update the backlog because it will push those features or user stories with less priority further to the back which may knock them out the release. This shows the impact when someone asks for a new feature, enhancements to an existing feature, or even directed interruptions to the teams.
Definition of Done adherence is key. Many project schedules are delayed because of the build up of technical debt where time has not been planned to fix. Projects which allow quality to slip by accepting user stories as done when they are only “almost done” will always be late because it more expensive to fix defects later than earlier. The goal is to maintain and ensure shippable quality and often this requires deployment of test automation.
User Story Refinement is key. The ability to prioritize user stories is critical to developing the right product. For high priority items, user stories must be broken into smaller stories which can be accurately sized with clearly communicated and understood acceptance criteria. User stories should be sliced so that they can be tested and reviewed and built into the product early. Proper user story slicing avoids late code integrations and fixes that always make projects late. User stories must be prioritized by business value because the ultimate measure of progress is the delivery of value to the customer.
Finally, let’s think about this analogy. Our family is going to drive the 3000+ miles from the east coast to west coast of USA to visit Grandma for Christmas. We want to be Agile, driving for a day, having a retrospective in the evening, and then decide where to stay or drive the next day. However, there is no need to start the trip if we do not arrive by Christmas eve. So we need a general plan which gives us some confidence we can make the trip within the required schedule, before we even start the trip.
Once we start, we need to monitor our progress by calculating our average miles that we have traveled per day. We can then use our actual travel data to update our estimate of the arrival date based upon this average. We can still inspect and adapt as we travel, the car may break down one day and we do not drive many miles. The children may want to visit a park, so we decide to stay in one place for an extra day. These are choices we can make as long as we are transparent and honest with our actual progress and understand how far we have to go. The same is true of an Agile software project.
In future posts, I will look more into the details on how to mature your projects so that you can become predictive. I will describe metrics which can help you be transparent about your progress and projections of estimates and dates. I will also talk about “research” projects where there are lots of unknowns or complexities which can be difficult to estimate. If you would like to learn more, please feel free to contact us.
