Today, a growing number of software development professionals are familiar with the agile development methodology, and are capable of executing a project given a backlog of well-defined stories. The problem we often encounter with new customers is the question of how to translate their business vision into an actionable development plan. The chasm between strategic vision and tactical planning is particularly acute in organizations with a history of heavy documentation or long term projects (> 1 year). In this blog entry, we’d like to share (at a high-level) the 5 steps that can take a team from vision to action.
Before we review the process, it is critical that you set yourself up for success by doing the following homework assignments in advance of initiating the Envision session:
- Dedicate a project manager or facilitator to the effort. It is not critical that this person have strong domain in your particular project, but it is important that they are well versed in how to execute agile projects.
- Ensure the availability of key stakeholders during critical stages of the requirements definition phase. Stakeholders can include product managers, legal department, sales or operations depending on the requirements.
- Ensure that Stakeholders have some conception of the end product already in mind
- Educate the entire team regarding the process to be followed. There should be no ambiguity with regard to roles or responsibilities.
With these, and other, necessary prerequisites completed, we are ready to discuss the process. For the purposes of this discussion, we will use a recent case of a customer who was modernizing their existing product and using that opportunity to add additional features in order to open new commercial markets.
Step #1 : Sketch the “framework” of a Project Plan
The first step in moving from vision to an actionable development plan is to build the framework for a project plan. This shell of a plan does not depict any of the actual development tasks, rather, it identifies the major milestones that occur during the development lifecycle.
In our example, the customer started work in August, 2008. It was important that they have a beta quality product in time for a user conference in May, 2009 and be ready for a GA release in August 2009.
Step #2 : Identify Release “Themes”
With the major milestones and drivers depicted, the team should turn its attention to defining a release schedule. A “release” is defined as a build of the code that is going to some consumer external to the development team. This could be an internal release, a release to a trusted external partner, a pilot release or a GA release. The important concept is that the release is installed and used by a group who has some interest in the state of the product.
To start this conversation, you might find it helpful to simply assume that the product will be released quarterly. Once those lines are drawn on the picture, it is productive to define a “theme” or a goal of each release. In our example, the customer decided that the releases would have the following themes:
- Q4, 2008 Release – Installed and used by the internal IT department
- Q1, 2009 Release – Used by a trusted partner in the field
- Q2, 2009 Release – Piloted as a Beta and used to satisfy User Conference Demonstration
- Q3, 2009 Release – GA Release
Once the high-level theme or focus of each release is understood, the team should participate in a facilitated discussion to identify the major components of the product. As you can see in the example below, the customer decided to focus on the core of their system in the initial releases (orders, payments), build integration and reporting during intermediate releases, then focus on less critical features in the final release.
Note: it should be noted that actual releases may not (and probably should not) be rigidly defined by modules. Instead, actual discussions will focus around business process. I’ve simplified this graphic for the purpose of this discussion.
Step #3 : Identify Use Cases
With a solid framework in place, the team should focus next on identifying the use cases or business flows that will be required in the application. In using the term use cases, I am not referring to the traditional multiple-page, multiple-day-to-complete document found on most waterfall projects. Instead, I’m referring to an agile use case which is no more than a simple title, notation of actors and brief description to solidify the intent of the use case. In all, it should take no more than 5 minutes to document once it is understood. Depending on the size and complexity of the application being delivered, the identification of use cases will take one to many facilitated sessions.
In our example, the client had just over 100 use cases identified across the eight primary modules of the system.
Step #4 : Estimate and Prioritize
The next step in the process is primarily focused on inputs from the development and QA teams. The team should be asked to provide the following information which will help flesh out the high-level development roadmap:
- Resources allocated to each release
- Expected Capacity (Velocity) during each Release
- Level-of-Effort Estimates to develop and QA each use case. This can be provided in either “points” or “development days”.
- Document all assumptions being built into the staffing plans or delivery estimates
After this step, management should have a clear sense of the needs on the team. This can range from staff to training to tools that have been assumed into the estimates. More importantly, there is a clear sense of direction on the path forward and a general sense of the feasibility of achieving the desired end-state within the given time frame.
Step #5 : Decompose R1 to Stories
The final step in the process is to decompose the use cases in the first release down to the “story” level, provide level-of-effort estimates, and assign the stories into Iterations. Coveros suggested two-week iterations.
At the end of this final step, your team should have an actionable first release, and a clear sense of what lies ahead in the coming quarters. Good luck with your requirements definition phase, and contact us if you have any questions or comments on this entry.
