How to accurately answer the Q "How Long Will It Take?"

At some point quite early on in each new project the question will be asked “but how long will it TAKE?”

If you’re in this situation, and your gut reaction is to try to start estimating everything, then STOP NOW! This will not work. The estimation will be meaningless and, moreover, if you do it this way you just lost control of the whole project.

Let me put it another way: Getting engineering estimates on multiple pieces of work and then adding those up to make “a total” is:

1. Deluded, because so many of these pieces of work depend on things you won’t learn until you have completed the preceding pieces of work
2. Outdated immediately, because your product needs and aspirations will change as you watch the project evolve (yes, I know you don’t think this applies to YOUR project but trust me: it does)
3. Negligent, because you actually just basically asked Engineering “how long would you like to take over this project?” and sure, while it’s important to listen to advice from Engineering about problems and complexities, it is no way to steer a project with effectiveness and control

So the only accurate answer to the question “how long will it take?” if you ask it, is actually “as long as you let it take”. This is not a good answer, not in a business with a finite cash runway and eager investors.

DRIVE the Project!

So rather than managing your project perpetually chasing after an ever-changing date and struggling to provide explanatory exec summary data to show why Actuals and Estimates are diverging (and they will), instead you need to DRIVE the project using the actual work items themselves.

“How?” you may ask. I will explain. It’s actually very simple.

Prep the Backlog

Single-phrase Story Titles

The first stage is to prep the backlog and actually, the less work you do on this, the better in many ways. As Mike Cohn said in his seminal book User Stories Applied, a story is just “a reminder to have a conversation”. So the best work tickets have just a single phrase or sentence as their title.

For example, this is GOOD:

“Manage banking connections”

And this is NOT so good:

“List, add and remove banking connections; connections should be shown in order of date connected; deletions should get a confirmation message first; adding connections should follow the initial journey from the onboarding wizard”

So, avoid word salad.

Intuitive “About a Week” Sizings

Product and Engineering will really need to work together and converse openly about what is and what isn’t likely in “about a week”. Each ticket needs to feel like approx one week’s work.

If I’m honest, this is the hardest part of the process. Crack this, and it’s plain sailing hereafter. Getting this right will rely on open, honest comms and a willingness of everyone to compromise on something.

You should be looking for agreements like “if we don’t want to include SMS verification we can fit ‘in-app signup’ into one week”, that kind of thing.

Note the added provisos (e.g. “no SMS”) under the one-phrase title, and move on.

Set Whole Project Scope

Once the backlog is prepared as outlined above, you’re going to need to grit your teeth and accept what is and what is not possible in the time available. If you’re a startup you likely have a very clearly defined pot of cash and a resulting very clear upper limit on the length of your runway.

Pick a Project Launch date (ideally not at the VERY end of your runway) and work backwards from there.

Having picked your end date, work out the number of full weeks between now and then.

This number represents the maximum number of tickets you can work on.

Now you need to decide, ticket by ticket, what is going into the Whole Project release. You will have to make sacrifices. It will be uncomfortable. But this is the reality of finite delivery and you are taking the pain all up front in this brutally honest session, rather than very very slowly over time, sprint by sprint.

So when you’re adding in each ticket, everybody needs to ask “do we REALLY need this?”

Consider / discuss swapping in / out other items - there’s nothing wrong with changing your mind (at this stage, or later - this is Agile) - all that matters is that at any time there are never more tickets than the number of weeks you worked out.

Accept Whole Project Scope

Kind of creepy, this step, but I feel it needs to be a recorded moment in everyone’s memories, a log of each person saying “I accept the scope of the project we just arrived at” or similar words.

People are very good at unconsciously thinking stuff like “yeah we’re saying this NOW but if we do well we can also get in feature X and feature Y and…” - STOP. There is no extra feature X or Y; there is only the Scope We Just Agreed.

So say it, one at a time.

Divide Into Releases

OK, creepy masonic rituals out of the way, we need to divide the Whole Project into releases which we will hit along the way. This is healthy for two main reasons:

1. By providing cadence points and tangible accomplishment / reward stages en route, It avoids burnout / project slog
2. Intermediate Stage Releases provide a natural (and very obvious) tracking mechanism without resorting to time-consuming project management tools (which often obfuscate the true status of a project)

What goes into each release? This will vary project-by-project. Only you know how to group stuff for your project.

As a general rule however, I’d recommend four to six weeks on average per release, and try to pick stuff that fits into that time bag. You’re going to have to do some thinking / reflection to take into account dependencies and the natural journey of the user (you can’t implement ‘Replying to thread’ before you’ve implemented ‘User can post’), but work hard to set these Intermediate Stage Releases to be meaningful, because they will very much help to focus your efforts over the coming weeks.

Start the Sprint

That’s it. Now all you have to do is to start the first week-long Sprint with the first approximately-week-long ticket, and then repeat this process each week, tracking the progress of each Release as you go.

There are some things you should bear in mind:

• Only discuss the detail of the ticket at the start of its particular sprint - keep it conversational and note down any key points
• Do not under ANY circumstances “helpfully” pre-load the task ticket with loads of requirement / detail / business logic / success criteria. You need to work on each item conversationally.
• Know that some things will take slightly longer than a week and some will take slightly less, and that’s OK
• Don’t be a slave to sprint dogma

Positive By-Products

If you follow this process you will likely notice some positive by-products which occur naturally as a result of the flow:

• Automatic Sprint Goals for the weekly sprints - The Sprint Goal is the single sentence from the ticket. Then sure you can go ahead and split this into tasks, bring in tech chores etc and make the Jira board as pretty as you like but the overall Sprint Week will have a very very clear goal
• No estimation meetings / pointing sessions - these are honestly the lowest point of any project and they just destroy all sense of progress, concentration, and hope
• Your product person has a clear picture of which ideas need nurturing and when - they no longer need to feel on top of the ENTIRE backlog ALL the time
• Reduced context switching at daily standups - there’s ONE clear goal for each sprint
• The dev project kind of runs itself

Good luck!

About the Author

I’m Mark Henwood, a highly product-focused CTO. I’m very much driven by trying to make the most natural and simple approaches yield the most benefit to complex projects. Please feel free to reach out to me on LinkedIn or email contact@mcbh.co.uk to get in touch.