How to Create a Milestone Schedule with an Agile Project Backlog

“We need to be agile these days.”

How many times have we all heard this message?  Things have always changed – what is true today is unlikely to be true next year – or even next month!  New information is coming, customer demands are shifting, how our teams work together is fluid.  If the dynamics of the last year taught us anything, it was that change is inevitable.

Given the inevitability of change, creating a static “Waterfall” schedule with all tasks and dependencies fully known at the outset of a project seems antiquated at best.  Yet, we all have large projects which do take time to complete.  How can we reconcile this need to be “agile” with the need to be able to plan?

Here is how we recommend generating a tried-and-true Milestone Schedule in an Agile fashion – specifically by creating an Agile Project Backlog.

1.Work Backwards to create User Stories

Start with: What does DONE look like for this project?

What are some of the major things that need to happen to be DONE? (These are called “User Stories”

How do these User Stories build on each other/are there dependencies?

For example: In order to have our Subject Matter Experts (SMEs) test the system, they need the right Permissions in our test environment first.  Also, in order to have SME’s test the system, they need to write their User tests first.  And in order to write their User tests, they need to review/document their processes.

Resist the temptation to become too granular with these dependencies!  Every little activity involved in how to create User Tests does *not* have to be listed at this time.

2. Order and prioritize the User Stories according to dependencies to generate a Milestone Schedule in the form of an Agile Project Backlog

Do not add dates or durations! At this point, a sequential User Stories list is sufficient. Some things do not have dependencies, or they can "float" before they gate later work. There also may be items that do not use typically constrained resources. These items can be highlighted as "opportunistic" work that the team can pull in when the people who will do that work capacity.

3. Ask the team members who will actually do the work to identify the major items they feel they will not be able to figure out on their own

Doing this up front allows the Core Team time to figure out the strategy for resourcing work that the team does not have the skillset to accomplish alone. In a software or automated equipment implementation, often this can be aided by the Vendor's technical team. For other projects, this may be finding coaches, consultants, temporary staff, or new hires to help bridge these knowledge gaps.

For example, in a software or automation implementation, if the team feels they will not know how to write the User Tests on their own, perhaps the outsourced Project Manager has done this before and can help (AJC does help with this!). The Core Team then can proactively do the leg work to be responsive when those User Stories move higher on the list, thus removing the knowledge gap roadblock so the team can deliver.

4. Ask the team members who will actually do the work to Commit to what they will complete in the Sprint

The team will size the highest priority items with relative points and pull as many of the highest priority stories as they can commit to in a sprint timeframe. 2-week sprints are very typical and a good place to start; longer/shorter durations can be determined in the RRP.

As the team is reviewing the highest priority User Stories, they will discuss HOW to get things done and may need to break them down into smaller chunks or sub-tasks that they feel will be accomplishable in the upcoming Sprint. Some of these items may not make the cut and will have to go back to the Project Backlog for the next Sprint.

If the prioritized items are ones with which the team has a knowledge gap, the Core Team should be ready with their resource plan for how to fill that gap so as not to inhibit the team's progress.

5. If the same resources are needed between different items, ensure that the most constrained resource agrees with the amount of work pulled into the Sprint time frame

This hearkens to the Theory of Constraints or "Bottleneck" theory. If one person is required to complete most of the work on multiple high-priority items, that person's capacity will limit the sprint. This may be a time where some "opportunistic" work that does not involve the bottleneck resource can be pulled in to make use of the other team member's capacity.

Also, if this happens often, consider in the Retrospective how to increase the capacity at the bottleneck.  Can you cross train someone? Can you hire in additional talent even if part-time? Can you offload other activities that person does to others? These suggestions can then be taken to the Core Team as a different kind of roadblock to resolve that will ensure the team continues to make progress at a timely pace.

6. Product Owner continuously reviews the Backlog to ensure that all User Stories remain accurate

The Product Owner (can be the Project Manager) needs to update the Project Backlog with any new information as it arises. They do not change the work being done in the current sprint, but they may add User Stories or reprioritize the Project Backlog during the Sprint timeframe so that the highest priorities for the next sprint are new. In system implementations, when a new customization is requested, the Vendor's team will often say something like "we'll see if we can add that to the next Sprint." This can be frustrating for the customer because they want whatever it is *now* - though it makes sense for the vendor's team of coders to work this way. (Completely different is the question about how to ensure that your customization request gets to the top of the next sprint - will save that for the topic of another article!)

7. Conduct a Review, Retrospective, Planning (RRP) on the last day of the sprint

Review what was accomplished in the Sprint in a high level, 30-minute meeting that Leadership and the Core Team participate in. After showcasing their deliverables, the team convenes on their own for a Retrospective on their process. They will discuss openly what went well, what did not go so well, and what could be done do better for next time. If there is any feedback for the Core Team or Leadership in terms of resourcing or removing roadblocks, one designee can take that feedback to them. Finally, the Product Owner comes back for the next sprint's Planning session. The team will review the the list, which is now reprioritized and improved based on the most recent information and determine what they will we commit to for the next Sprint, including if there is anything which is not yet complete from the first. They should also identify if there are any new User Stories for which they have a knowledge gap, or if anything previously identified has changed (maybe they know more now and no longer have a gap in a future area).

8. Be Patient, Give Grace, and Keep Going!

It may not be possible to determine at the outset a specific “Complete” date for this work, especially if this is the first time your team has executed this type of project.  However, as you get better at relative sizing for the tasks, you can start to predict how much work the team will complete in each Sprint and forecasting completion dates will then become clearer.  You can also pull out “extras” and work to “MVP” (minimum viable product) the deliverables, saving additional features or complexity for “Phase 2.”

Do not let Perfect be the enemy of Good!  Get something done and learn with every iteration – then when change hits, your team will have all the tools it needs to be agile in response.