Agile Release Planning – the preparation phase

Before I start, I want you to read the following statement:

“The most important role of PO, project manager and the team is to create a product that someone wants to buy, from which company can earn some money, and in return pay you something back. In process of creation, you need to respect the law and make sure that people are treated with respect and dignity. Anything else is a second priority”.

Some time back, I spoke about “Iron Triangle” and how critical is to know upfront which project lever (functionality, date or release) are at your disposal for adjustment as you start with the planning. Failure to ask this to stakeholders is a sign of immaturity or lack of confidence, or both.

Once that is clear, you look into the feature list which is presented by PO at the kick start of the project. That list can’t be longer than 10-15 items. This list must survive “so-called” elevator test (from Geoffrey Moore’s “classic” Crossing the Chasm), and it goes like this:

  • For <target customer>
  • Who <statement of the need or opportunity>
  • The <product name> is a <product category>
  • That <key benefit, compelling reason to buy>
  • Unlike <primary competitive alternative>
  • Our product <statement of primary differentiation>

These items are not “epics”, these are your FTPET’s (I just made that name now, features that passed elevator test). For the stakeholders and the outside community, these are only sellable items, and you need to track them separately throughout the project lifecycle, next to all other working items (stories, epics, tasks, subtasks, whatever – these are too technical terms for the rest of the folks).

In the first phase of the project (between M1 and M2 from the project milestones blog), you need to organize a workshop. For more info, I recommend a book “Practices for Scaling Lean & Agile Development“ by Craig Larman and Bas Vodde.  Short version: go for a separate location with key guys, make sure you have enough white boards around (and camera to capture drawings and discussions) and do the following (extract from the book):

  • Envision business case, strategy, high-level list of features (major scope), and constraints for the release.
  • Identify ten or twenty percent of the features that deserve deep analysis immediately.
  • Choose a subset that will yield broad and deep information about the overall release work. There are always some key features that, if deeply analyzed, give you overarching information about the big picture.
  • These may be the most complex, the most architecturally influential, the highest-priority features, or features with the most obscurity. From the viewpoint of information theory, they represent a subset that, if analyzed, is most likely to have lots of surprising information—the most valuable kind (end of ref)

Once the workshop is over, create a small sketch plan on A4 paper. If you need A3, you are already in trouble. Divide it into 4 quarters (Q1 to Q4) and draw the activity diagram, similar to story mapping, but taking into account only major items, including FTPETs and most important non-feature tasks (what ever that is).  Small tip: for god’s sake don’t use week numbers instead of quarters, most of the people outside

of project circles can’t actually tell you in which w## are they. It would also give a wrong impression that your precision will be in weeks – and it is not. This paper will be your basis for a discussion with R&D folks, key architects with whom are you going to make a more detailed plan. Right now, you need this paper as a tool to check the dependencies, and get a first feedback from R&D. After few sanity checks on the white board, you will know whether this plan makes sense, nothing more. If people can’t tell you this at least, you either have not done a great workshop, or you are surrounded by wrong people (next tip in later case: if you can’t change the team around you, change the team around you).

Depending on the team size, and whether the team is collocated or not, you will need to split development to one or more feature teams. Each feature team must have a feature owner, call it a scrum master, what ever. He should be leading feature discussions with PO (to come up with more detail user stories), lead technical discussions with R&D folks, and make sure that all ideas are captured in the wiki, with drawings, mockups and design choices. Here is one example of feature mockup in the wiki:

Once the key items passed this phase, you need to ask scrum masters and devs to add all KEY user stories, FTPETs and major tasks in the system (in our case JIRA). By then, about 30%- 50% of all features are well understood. Reminder: after workshop you tackled 20% of the features, few weeks later you are at 20% of the time span of the release. This is your milestone M2. 20% of time required for analysis is rule of thumb, BUT, you should not cross it too much.  If the time is the most important dimension, everything that has not been discussed at this stage and it still looks complex to solve, must be out of that release (or at least be given very low probability of success in that release). Here is what you can do next, create a feature list with the following items:

  • Key (JIRA or something similar)
  • Summary
  • Probability
  • Rationale (Grow, Harden, Customer etc)
  • Priority (P1, P2 or P3)
  • Comment
  • Size (relative) in story points

In my previous blog, I talked about story points estimation. Now you can see how I use them (R&D still can use them for other things). The size of the feature  is a story point given as a relative number. I can sum all stories together and provide a quick overview to PO on where the majority of the effort of this release will be spent (like in the picture above, which is made by one simple wiki macro). It also provides me with a tool to give a honest/professional feedback to the stakeholders about probability of the success of any given feature. Please also note that for the test and doc effort estimation I use T-Shirt estimation sizes (S,M,L,XL).

Rationale category is important information for PO and stakeholders, as based on this info we can all see in one pie chart whether we are making this release as the result of the push effect (bring a new functionality that is unique to the product), the pull effect (customers ask for new features) or we are busy with tasks such as improved scalability, some major redesign, or refactoring (resulted from “Demo Driven Development” syndrome).

Once you have your skeleton plan and 30%-50% of all features well understood (including the most complex in this bucket), you are ready to go – you have your milestone M2. Now the fun starts! Stay tuned for the next blog, it’s coming….


P.S. Comment  on the first paragraph:

When I became a manager some years back, I was told that I will be measured by “Whether the project is delivered on time, with agreed budget and all features implemented”. I believe now, as I did at that time, that this is the worst possible message (and metric) you can ever give to a young manager.


Leave a Reply