Planning

This category contains 52 posts

Estimating value bottom up and top down

In all organisations it’s really important to be delivering the most valuable thing, and in many organisations it’s obvious what that is—and people just get on with it. But in many organisations—particularly large ones with many competing demands—it’s important to estimate the value of our work to determine what gets delivered next with the limited … Continue reading

Flat pack estimation

It’s well-established within the agile world that delivery teams—and particularly individuals—are terrible at estimation. We do estimate, still, and hopefully we get better with time, comparing forthcoming work with past examples, for instance. But it often remains a wonder to those outside the immediacy of delivery teams just how misjudged our estimations can be. “It’s … Continue reading

Always build for real people’s real problems

I’ve been having fun this week watching some conference talks about my current favourite language, Elm, at Elm Europe 2017. And I enjoyed seeing an important idea discussed—important not just for coding, but for product and project development generally. The lesson is: solve the actual problems experienced by actual people. Don’t generalise—at least not without … Continue reading

Hubbard’s powerful question: What decision do we want to support?

Sometimes a piece of analysis work can be very open-ended, or at least there is a danger that it might go on too long. Examples I’ve come across are reviewing some old code, going out to understand a process, implementing a spike, looking at a competitor, etc. It’s not that such activities are inheritently bad, … Continue reading

The cost of delay of technical debt

Last week I wrote about the value of stopping work to tackle tech debt, and more specifically when we might expect to recover from the temporary stoppage. In the ensuing discussion a question came up about one of my assumptions, which was that the team was delivering at a constant rate (albeit below its potential). … Continue reading

Should we stop to address technical debt…?

One of the questions that arises with many teams I work with is: Is it worth spending an iteration (or more) not delivering any features but just working on our technical debt? This is by no means the only way to deal with tech debt—most people (and I) favour addressing it a bit at a … Continue reading

The benefits of timeboxing a solution

A colleague pointed me to a nice article by Sue Davis about writing for the public, and among the suggestions was the idea of timeboxing feedback: “If you don’t, the polishing process can be never-ending and you risk delaying getting the content to your users.” Timeboxing is really valuable not just for getting feedback, but … Continue reading

There’s trouble in MoSCoW

Most project teams I work with prioritise their work in a simple order: most important, second most important, etc. But sometimes people still use the MoSCoW method, and I find this leads to problems. MoSCoW stands for Must, Should, Could, Won’t—it’s a way of categorising deliverables into one of four buckets. The Musts get done … Continue reading

Frequent delivery is the test of a plan’s quality

There are many ways to measure a plan’s quality. Some of these are: flexibility, how realistic it is, and the number of internal or external dependencies. But in the end for most people a plan is about delivering some end result within some stated time. A plan shows both approach and time—How and When. It … Continue reading

Prefer a backlog to a scope

I was speaking to a colleague recently about how her teams were getting on, and she said, “I’m pleased that we’re talking more about prioritising a backlog, much less about what’s in scope. That’s really good.” And it is good news. It shows that the teams are thinking much less about a single large edifice … Continue reading

Advertisements