In preparing for battle I have always found that plans are useless, but planning is indispensable. - Dwight D. Eisenhower

There is a common misconception in Agile that we don’t do much planning. Agile is supposed to be all about cowboy coding and flying by the seat of your pants, or so I keep hearing. Rubbish! Those of us that have been practicing Agile for a number of years, know that nothing could be further from the truth. We know that it is a myth to believe that Agile methodologies cannot operate in a hard date-driven environment. We know that having a plan, is incredibly helpful when trying to manage  risks and dependencies. We also know, understand, and embrace that these plans are subject to change. However one of the most difficult aspects of Agile (or any other) project planning, is managing risks and external dependencies. These issues can cause delays and expensive interruptions in your project. In this post, I am going to focus on a few methods I’ve used to help plan and manage risks and dependencies in an Agile project.

Roadmap/Delivery Plan:

The Roadmap (or Delivery Plan) is an artifact, which deconstructs the Vision into a long-range plan by releases. This is usually created during Sprint 0 (or project start) and updated, at a minimum, at Release Planning. Ideally it is updated at the end of each Sprint. The Roadmap consists of themes and/or high-level stories (epics). The objective is to figure out, at a Release level, when these stories are being delivered or when they need to be delivered. Part of the exercise of building the Roadmap involves identifying and evaluating risks, as well as dependencies during upcoming releases. See the example artifact below.

Image may be NSFW.
Clik here to view.

Release Plan:

The Release Plan is an artifact, which deconstructs the Roadmap into a high-level plan for each release, by Iterations. You only need to capture the high-level stories at this point. However, if you have a groomed backlog and know your team’s velocity, you can replace the epics or themes with actual stories and list the velocity per sprint. It is a quick information radiator to determine if you will be able to meet your sprint and release goals. You place the risks and dependencies you identified in the Roadmap into the Iterations you expect them to occur (if known). This gives the team a sufficient amount of time to prepare for upcoming risks and external dependencies. Generally, due to all the changes that occur during a Release, you only need to plan out enough Sprints to satisfy a single Release. The release plan is also created at Sprint 0, updated at the end of each sprint, and created at each release planning session.

Image may be NSFW.
Clik here to view.

Give To/Get From and Risk Stories:

Risk Stories

Thus far I’ve described planning and managing dependencies and risks at the Release level. At the Sprint level, managing external dependencies and risks is relatively straightforward. If you understand the risk, and it is both impactful and probable, you can often write stories to take action to mitigate the risk. Obviously you don’t want to write a story for every risk, so only pick the ones that are likely to happen and have a impact and probability greater than 3. So, you wouldn’t want to write a story to deal with a potential meteor strike, however you may want to put a story in the backlog to deal with a risky architecture issue.

Image may be NSFW.
Clik here to view. Image may be NSFW.
Clik here to view.

Dependency Stories

A Give To or Get From story is an external dependency management story. You are expecting to receive something from another team, vendor, etc. (Get From), or you are expected to deliver something to another team, vendor, etc. (Give To). In general, a Give To/Get From story is the same as any other user story with the following exceptions:

• There should be emphasis that the Story Point estimates and tasks are only for the work your team will do; since you cannot control work that is external to your team, it is not factored in. As a result, this will often be a low Story Point estimate. For example, this Get From story could be part of a larger epic on front-end website performance:
  • As a Systems Engineer, I want to get a performance report from Vendors A,B, and C, so that I can determine if their software’s UI response time will meet our .5 second threshold.
• You will identify whom you have the dependency on (Get From) or who has the dependency on you (Give To).
• There is a specific date of when you expect to receive or give the dependency resolution. This is used to give you plenty of time to prepare for the delivery (or if necessary, delay).
• There is a clear description of the dependency and the expected resolution (Acceptance Criteria).
• You NEVER write a Give To/Get From story for your own team (internal dependencies). Since you can control that work, the scheduling of the story and any potential impacts will be handled by the Product Owner and Scrum team.

Conclusion:

It is important to understand that the previous items are simply describing tools, processes and artifacts. They are NOT replacements for the values of Agile, the first of which is: We value individuals and iterations over process and tools.

In conclusion, don’t use these processes and artifacts as an excuse to not have a conversation about risks and external dependencies. Instead, use these tools, processes and artifacts to enhance the conversations you are already having .

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.