This category contains 57 posts

More effective risk workshops

A common part of the traditional risk management process is to run a risk workshop. This typically involves getting a group of stakeholders together at the start of a project, and asking what might go wrong. Not only is it a good thing to seek out problems before they happen, it is constructive if we … Continue reading

The coffee estimate

Rough estimates can be useful—they can help us understand whether or not it’s worth undertaking a piece of work, or whether it’s worth digging deeper. But there’s a well-known danger, too: they can be misremembered as promises. “About three months” can easily become “But you said three months”. The problem is often that although the … Continue reading

Making best use of time in an investigation

A while back I wrote about “The investigation “sick note” card”, in which I said I often found teams opted for investigation work as a way of avoiding doing the actual development work. Investigation isn’t a bad thing, but I felt that it’s purpose was often missed. Here I want to go into a bit … Continue reading

Separate solutions from outcomes

One of the most useful pieces of advice I’ve had on analysis is from Tom Gilb, when he talks about separating solutions (which he calls “design ideas”) from the outcomes we want to achieve. He’s primarily addressing the early stage of a project, before the build has begun. But it’s also relevant to the build … Continue reading

What is the right size for a user story?

Generally speaking I encourage people to make their user stories smaller, not bigger. But I will long remember an excessively heated argument many years ago with my former colleague Mat Wall in which he was adamant that I was going too far by insisting on stories which where too small. In that case he was … Continue reading

Generalising the product development pipeline

I’ve been involved in the development of a number of product development processes—which is to say, the creation of the pipeline from idea to reality. The outcomes are always useful, and always sightly different. But there are commonalities, such as the breakdown of the process into various phases. These are usually combinations of Concept, Exploration, … Continue reading

Why election promises are like fixed price contracts

The public like confident politicians who exude certainty and give clear answers. We get a feeling that they’ve got everything under control, and they’re the people to vote for. Equally, it’s frustrating when we hear them flim-flamming in the face of an apparently straightforward question. Why do they do that? Is it because they’re just … Continue reading

Delivery beats analysis

Some projects are hard, and the requirements are mysterious. They’re the kinds of things that look fine when you start, but sooner or later you get into some really nasty details. Should the third level of XML be in this format or that? Do they want us to use this URL scheme or that one? … Continue reading

Determining success of a metric

If you’re developing a digital product in a smart way you’ll want to be tracking the metrics from the features or changes you introduce. But how do you know what a “good” result looks like? For example, you may want to test your assumption that people will sign up for your service. You may even … Continue reading

The development pipeline starts with the customer

Just that. Many people think of the development pipeline starts at the point where the developers pick up the next requirement. And it’s true that if you work in a large organisation that treats software production like a factory—or which is just siloed—then that’s all you may ever see. You may even spend a happy … Continue reading