This category contains 52 posts

If you can’t measure, prioritise

When planning a piece of work we can often find ourselves trying to measure or score the various features according to their value. For example, if our project is to attract new users to our product then Feature A might be measured as expecting to bring in 800 new users a month, while Feature B … Continue reading

Agile teams have more responsibility with less planning

Some people think agile teams have less responsibility because the plans are looser. In fact the opposite it true. When organisations start their agile journey, there are—inevitably—slips and confusion along the way. One thing that often happens is that the reduced up-front detailed planning leaves those outside a team to think there is “no planning” … Continue reading

Good plans are flexible

What makes a good plan? Superficially a good plan is one that delivers what we want. And certainly if a plan does end up delivering what we want then we can look back and say it was—at worst—good enough. But in reality it’s very rare that the plan we start off with is the one … Continue reading

Questions for developing a product idea

I often talk to people who have an idea for digital product and want to discuss how they might go about developing it. Recently I was speaking to others who have similar discussions with people, and we shared our general approaches. So here are two questions I ask when discussing the development of a new … Continue reading

Don’t focus on greatest value—focus on fastest value

Agile focuses on value. This is good but when it comes to prioritising we could be more refined than prioritising greatest value. Instead we should be focusing on fastest value, which is slightly different. The literature on cost of delay is where we find the explanation. It tells us to prioritise by something called “cost … Continue reading

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