[This post in German]

Recently, I visited a client where I’d been several times assisting the company’s PRINCE2 implementation. Over the years, multiple attempts to tailor PRINCE2 to the company’s environment were started and implemented in pilot projects, with varying results. Two years ago, the client started a very big, mission-critical software project expected to develop a replacement for their main manufacturing information system. The project should be finished by this summer, but that won't happen. The big question I was faced with was: How can we know when it’ll be done?

Primary note: This story is generalised to be anonymous and exaggerated to make my points clear.

Background: The Situation

Half a year ago, when I had last reviewed the project’s progress, we’d been discussing their use of PRINCE2 and how that combines with the supplier’s usage of Scrum. Due to a total mismatch of planning paradigms, they had a lot of issues regarding the alignment of their plans. They had split their project into management stages—good—but basically established a waterfall plan where management stages were named Analysis, Design etc. That way, they cut the possibility for learning from the model, which definitely reduced their chances to inspect and adapt.

I asked them if the project was supposed to deliver one big-bang solution in the end or if they had thought of incremental delivery. In fact, they were planning an incremental replacement of the old system and, as the supplier was using Scrum, they got a potentially shippable version of the software every three weeks. I asked, why isn't that shown in your plan? I explained the management stages as stages of incremental delivery and refinement of business requirements, to frame a few of the Scrum sprints. We changed the layout of their product breakdown structure to get rid of the waterfall phases. Instead, we structured along the parts of the system, focussing on business dependencies and business value. That way, they could incrementally break down those products into prioritised work packages for the supplier's product backlog.

The Estimation Problem: a Mass of Cards

In between that visit and last week, they had further refined their product planning technique. They told me that communication on progress had been greatly improved and that transparency of short-term planning was good. But now they had a new problem, which became apparent when the client project manager entered the room and asked if the overall plan update was done as expected and if they could tell him the expected delivery date… I asked how can it be difficult to plan the delivery date when you have measurable progress with fairly constant velocity of the Scrum teams? They were missing estimations. They didn’t have estimations on all remaining work packages, and although they had analysed dependencies, they didn’t know how they would influence the overall plan. They showed me their planning wall:

All cards are work packages, some of which have detailed technical tasks planned (the small vertical paper strips). Cards in a horizontal line mean technical dependencies. Most of the cards were not estimated. They were expected to name a date within one week—and this time it should better be viable, as they deferred it twice already.

Advice: Three-Staged Approach with Speed Estimation

My advice:

First, invite a few experts from the teams covering all parts of the system to review the dependencies. Have business experts in the room to answer questions. Give them one hour time to look at the dependencies written on the cards and let them find ways to reduce them, for instance by splitting cards. After that, make detailed photos of the wall so you can take down all cards without losing the information.

Assemble the full team (more than 30 developers) in one big room with four tables. Put labels on the tables according to four sizes: big, medium-big, medium-small, small. Hand out the cards and let the developers decide on which table to put each card. Let them form small groups to shortly discuss the feature requests. Do that fast, and when all cards are sorted on the tables, allow for one more hour of going around the table and moving cards to different tables. Have the business experts in the room for questions. Have the management team and the experts (about eight people) watch that process closely so that they can identify cards that move multiple times between different sizes. If you identify such a card, stop the full process and ask, why do you think this card is bigger/smaller than the group it’s been in? Agree on a pile that card should belong in, clarify questions until that agreement is reached. After about three hours, you should end up with four piles of cards of roughly comparable size. Thank the group for their efforts.

As a third step, use the team experts from stage one again. Pick three cards (randomly!) from each pile and have them estimate these as you usually do (with the same type of estimation you use as basis for your velocity calculation). Use the mean of this estimation to calculate the size of each pile. Draw the mean estimate on every card in each pile. Add the piles’ estimated up to get an estimation for all the work left.

How do we get a Date?

After these three steps, you can calculate the date of the earliest possible delivery from the overall estimate and your velocity. You should allow for a certain offset due to the identified dependencies. To estimate if such an offset is needed, reassemble the cards on the wall. Evaluate the dependency chains and see if there are big cards blocking the flow of smaller ones. Try to break these down into smaller parts with less dependencies. Repeat that until you have no more blocking dependencies or you can estimate how much these chains postpone your estimated end date.

I hope you can use some of this advice for estimation in your projects! How did you solve similar challenges?