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.

Agile Software development – high-level planning

As at the point described in my last post, we had created a pile of story cards, representing a Prioritised Requirements List (PRL). Each story had associated with it relative benefit to the business, a story-point estimate of relative size and complexity, and a MoSCoW-scale prioritisation, a DSDM concept.

Now, how are we going to deliver solutions to these requirements, and just as importantly, when?

Our first task was to group all of the user stories into ‘Themes’ of related requirements. This is so that we can decide what functionality can be released into Production together. In our case, requirements or features of particular parts of the site were grouped into Themes. Those stories referring to features of the new Home page went in Theme 1, those related to up-sell and Claims (did I mention we are an Insurance company) went in Theme 2, and those related to Amendments went in Theme 3. Generally speaking, Theme 1 should be the most important and deliver the biggest benefit, but in our case, although it does deliver business benefit in its own right, it is more an enabler for Theme 2, when the big benefit is realised.

Themes are also known as Increments or Releases. I am inclined to use the term Themes when referring to user stories with the Business, and Increments when talking to the technical guys, but the terms are largely interchangeable.

From what I have read so far, all Agile methods (XP, or eXtreme Programming, Scrum, DSDM, etc.) have in common the concept of working in short periods of time called timeboxes or iterations. DSDM calls them timeboxes, so I will adhere to that term here. Each Increment comprises a number of timeboxes, so that a theme develops incrementally over a number of timeboxes until it is in a cohesive state, when it can be delivered to Production.

Within each timebox, a sub-set of requirements (stories) is analysed in detail, the solution is designed, developed and tested, and preferably deployed. DSDM differs from the others in that it allows for the probability that work will take longer than estimated but allows for contingency in the form of additional, lower-priority user stories (Could Have’s).

What we are trying to establish at this early stage is “how big is this project, and when can we deliver it?”

To get the answer to this question, it is necessary to translate the story points into a measure of duration. This brings to the fore the slippery subject of estimating. To estimate the effort involved in delivering all of the stories listed (we had over 50 of them) would have taken virtually an entire day. We therefore adopted the idea of estimating only the stories in Theme 1. This would give us a reasonably accurate estimate (with a 70% confidence) of a delivery date for that Theme or Increment. I then took the total story point count for Theme 1, and divided it into the total effort estimated to give a ratio, that I then applied to the total story point count for the stories in the other Increments.

I then played around with some figures in Excel (as managers are wont to do), to try to work out the best duration for each timebox. Generally it is better to have short timeboxes than long ones, and for completely the wrong reasons (don’t even go there), I settled on a standard duration of ten working days.

Knowing how long each timebox would last, how many people were assigned to the project (three, plus a part-time tech lead), and the estimated effort required, I could easily calculate that we would need 11 timeboxes to deliver the entire project.

Right, that’s the high-level planning done. Now for the detail.

Condor to be outsourced.

A workshop was held yesterday, the purpose of which was to work out an action plan for the next 30 days. Why 30 days? Well, that takes us to virtually the end of the year.

The new programme manager for Condor, E, said that in order to have even the remotest chance of getting this project implemented by mid-year, we need to have some requirements and some high-level designs by the end of this year. And he's right! So what do we need to to do achieve that?

The group identified several separate work streams - Requirements, Design, Testing, Business Operating Model, etc. A team leader was appointed to each, and other people allocated to each work stream according to who the group felt was best suited to performing the tasks identified in each. It's a decent enough approach. For me the biggest disappointment of the day was seeing representatives from an outsourcing company in India present. It is obvious that E has already made the decision to outsource a large amount of the development work.

The end of the meeting was by far the most revealing.

On a flip chart, someone drew a mini Gantt chart showing, against the project timeline, the major activities and milestones that we would need to hit to make the plan work. The level of overlap between activities made it obvious that, either we were simply not going to do it, or we were letting ourselves in for the mother of all managerial nightmares.

E finished up the meeting by saying that while it appeared as if the plan was... um... challenging, he was not prepared to go back to his boss and say it was not do-able, until the various work streams generated the estimates to prove it. Smart cookie. E is no fool, and is obviously a very experienced and competent manager. He is surrounding himself with people he trusts and who he knows can do the job.

Planning to Fail

When I posted (here and then here) that I was sceptical about the plan to deliver Condor in 6 months, it now appears that I was not the only one. At a meeting earlier this evening, it transpired that I am being instructed to limit our involvement in the project not only to protect the other projects on the portfolio - although there is an element of that in the mix - but also to limit the damage should the project fail.

It was even suggested that the web front-end component should be outsourced to India. This would have two benefits - relieving us of the need to resource it ourselves, and providing someone else to blame when the plan slips.

The fact that The Parent Company is willing to fund and resource a large part of this project means that our part of the company is happy for them to go ahead and get their noses bloodied, while we merrily go on delivering the other planned projects on our workstack.

Why can they not create a realistic and workable plan to succeed, rather than playing political games to limit the damage of failure? Perhaps the fallout from the US mid-term elections has had consequences far beyond the boundaries of the United States, in ways no-one predicted.

This project is starting to get a distinctly nasty smell attached to it.

It is situations like this that make me glad I am publishing these comments anonymously.