Increment Planning

In an ideal world, all of the candidate user stories will be perfectly defined and understood, and all of the preparatory work will have been done by the business in advance. It is often the case, though, that there is not quite universal understanding of all the stories, and some clarification is required before the size of each can be estimated.

For my project, being a redesign of a part of our web site, the business have created mock-ups of what the new pages should look like, in some cases with HTML and CSS, which of course makes integrating them into the final solution that much easier, and more accurate. It is very worthwhile getting the business to provide a visual representation of the solution they want – it is an invaluable aid to understanding.

It is also very worthwhile discussing the candidate stories about a week in advance of the start of the Increment. My project plan showed timebox 4 (in Increment 1) finishing on the Wednesday, and timebox 5 (the first for Increment 2) starting on the Thursday. In reality, timebox 5 will have to kick-off a day of two later, to accommodate the story analysis and increment planning.

Representation from all key stakeholders is essential. We have a number of stories which generated some animated discussion between two different business areas. Resolving these discussions is essential to determining how the solution will be developed; without everyone’s active participation, there is a very real risk of developing the wrong solution.

Ensure you have enough time. Plan on a full day to get the most out of it.

It is essential that you do not get drawn into too much detail at this point. The objective is to ensure that everyone understands the requirements, and the stories for the first timebox can be selected. It is not meant to be a design discussion. If conversation starts getting bogged-down in detail, move on.

A facilitator helps enormously. Without a structure to it, these sessions can break down into mere discussions, with no direction or meaningful progress. Increment planning should have an agenda something like this :

• Introductions – make sure everyone on the project team is present and knows who everyone else is and their role, both on the project and in the meeting.
• Functional Overview – opportunity for the business to provide an overview (preferably visual) of the objectives of the Increment.
• Candidate Stories – the Business Ambassador presents each candidate story. Ensure that everyone present understands the requirement of each story – understanding how it will be delivered is not necessary at this stage.
• Estimation – generate estimates of the relative size and complexity of each story. This can be in ideal-days or in story points. I prefer story points, because it provides an objective measure of progress. These estimates are also essential to ensuring that there is sufficient ‘contingency’ available in the form of ‘could have’ stories.
• Prioritisation – MoSCoW prioritise each story according to its business benefit and contribution to the business vision.
• Selection – based on technical or business dependencies and priorities, select the user stories that will be delivered in the first timebox.

So, in summary:

• Get the Business to prepare their stories and any visual aids in advance
• Plan for a full-day session ahead of the actual Increment start date.
• Ensure all stakeholders are present, as well as the entire project team, including testers
• Get a neutral facilitator to run the session.
• Don’t get into any discussions about designing the solution. Just understand the requirements.

Increments and Timeboxes

Having divided the entire Prioritised Story List into three distinct Themes (or Increments in technical speak), we have just finished work on the first increment. Well, sort of. We have deployed the last of our stories into our test environment, but there are still some bugs outstanding, so we will be dedicating some time to fixing those over the next week or so before we put it live.

So we have now arrived at another Increment boundary and I have learned another lesson: Increment planning should be done in advance! Until yesterday, I was under the impression that we should ignore the second increment until we were finished with the first. But yesterday’s planning session was slow going. I also made the mistake of confusing it with a timebox kick-off, so I was expecting too much from the session.

It is therefore important to distinguish between an Increment Planning session (in which the candidate user stories are reviewed, clarified, understood, and prioritised), and a Timebox kick-off, in which the stories selected for development within the upcoming timebox are broken down into development tasks and estimated.

My next post will contain a few guidelines for conducting Increment Planning sessions.

Am I Agile by nature?

Traditional project management methods emphasise control. There are a myriad of processes and tools (with attendant templates) to impose control over the chaos that is typical of the average IT project.

Not least of these is the bizarre addiction to MS Project. I know few people who use it well, and even fewer who actually like using it. I hated it! Still do. A company I worked for until recently insisted that all projects use one of three templates (and had a department monitoring adherence - QA they called it!!). The different templates were intended to be used for different types or sizes of project, and differed in the number of standard tasks that were listed.

The problem with MS Project templates of course is the tailoring needed to make them fit the reality of the project you are planning. And in typical waterfall projects the plan tends to change on an all-too-frequent basis. I found myself having to manage the plan, rather than the project, because that was what the company expected of me. How unproductive is that?

I knew that there was a problem with this approach to project management - this management by template - I just didn’t know how to express it. In essence, it takes away our focus on the most important element of any project – the people. It forces managers to focus on the administration, the bureaucracy, the paperwork.

In our fairly extreme implementation of Agile practices, MS Project is not used at all. Our planning is done on two levels:

• How much overall work is there, how long will it take, and how many people are required?
• What detailed tasks are we going to work on within the next timebox (1-4 weeks)

Now that I am able to more simply monitor – not control – the task plan, I am utilising my time to better effect. I am more effective in leading the team forward, and I am happier as a result. Perhaps I was born an Agilist?