Planning

This category contains 57 posts

Impact estimation tables (roughly)

Last week, two days in succession, I had cause to solve a problem using impact estimation tables. Unfortunately this technique is not widely known, so I thought I’d have a quick pass at explaining it. For many more details—beyond the simplicity of the description below—you really need to see the work of Tom Gilb, who … Continue reading

A bad time to estimate

The other day a friend and I were discussing a project which had notably overrun its original expected delivery date. “The problem is,” he said to me, “You estimate a project at the point you understand it the least.” This is a great phrase, and good to remember, even though it’s not strictly true. If … Continue reading

A plan for a plan

The other day a developer in my team asked, “So what’s your plan for…” and then described a particular organisational and technical challenge that several of us had been discussing on and off for a while. It was something that I was pushing forward, but I didn’t have all the answers yet. Of course, I … Continue reading

Product through customers

In the last couple of years I’ve met a few people who have been challenged by balancing building a product suitable for everyone versus building a customised product suitable for just one customer. The challenge is that while building a product suitable for everyone is clearly preferable, it takes a huge amount of time, and … Continue reading

How much time should we put aside for tech debt?

I’ve talked previously about technical debt. Should we stop other work to address it? What is the cost of delay? And that we should watch out for technical bankruptcy. But these are “stop the world” questions. What proportion of our time should we be spending on it on a regular basis? Is 5% too little? … Continue reading

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

Advertisements