planning - Matt Kimber

Matt Kimber

planning

A collection of 10 posts

Steak and Salami

Steak and Salami

Ever had the feeling you're working constantly and getting nowhere? Specifically, the one where you've got a dozen things to do and none of them are getting done? Did you find that the more you worked, the worse the problem seemed to get? This is something endemic to the modern,

Agility and the power of No

Agility and the power of No

One of the nice things for me about writing is I get to go back to my old articles every once in a while and see where my viewpoint has matured, where it's changed...

Technical User Stories - Who, What and Why

One of the problems we regularly face with our more technical stories (for example, setting up a monitoring stack) is explaining to the people in charge of the budget why they should pay for this. It's a valid question. I think it arises because when we're writing technical stories, we

The Backlog

I had one of those "changing the way we work" discussions today, about the product backlog. I'll spare you the details, but it came down to answering two questions: 1. How many of the stories we know about should we have on the product backlog? 2. How many of the

Planning isn't free

Planning isn't free

I've got a confession to make: I secretly enjoy rewriting code when requirements change. I get to think again about what I was doing and my assumptions, tidy up the lingering technical debt, make a few performance optimisations and abstract things a little bit so I don't have to worry

Budgeting

Budgeting in a typical organisation where you have a few teams of full-time developers can be counter-intuitive. The monetary cost is fixed; your developers get the same salary whether they're building products, fighting fires, or goofing around on Facebook. What you're actually budgeting is opportunity: making sure that everyone is

Why tasking matters

Why tasking matters

Something I perhaps neglected in my talk about breaking down user stories [https://mattkimber.co.uk/breaking-down-user-stories/] into tasks is why you'd want to do that. Let me illustrate by analogy. When you're hiking, there's a question you're continually asking: "where am I in relation to where I should be?

Breaking down user stories

Breaking down user stories

A user story is a short, simple description of a piece of functionality, as told from the perspective of a customer. It's intended to form the basis for a discussion about how to provide business value, and it should be relevant to the customer. "I want to be able to

Necessary and sufficient

One of the teams I work with is about midway through a project, and we're starting to take stock of what's gone well and what we've learnt that we could do better next time. (This kind of reflection is normal and healthy in an agile environment. It's when you don't

Painting by numbers

I'm a real fan of estimating things by doing relative sizing with planning poker cards. The cards mean everyone gets a say, the Fibonacci-like number sequence of the deck avoids getting bogged down in differentiating between tiny graduations in task complexity, and the relative nature of the sizing… ...well, that