Previously, I said that one way for teams to get better quickly is to make their User Stories smaller. 3-5 points, half a sprint or less. This is a great way to improve your team’s overall output, quality, and flexibility. But sometimes, User Stories can get too small. When I was still very new to Agile, I attended a workshop where they talked about writing your User Stories super small. Their team had shifted from counting Story Points each Sprint to the counting the number

“Relative sizing with story points.” You’ve probably heard the phrase, but it can be hard to wrap your head around the idea. If you haven’t heard of it, here are some resources: Definition of Relative Size Using Story Points for Sizing It can’t be as simple as it sounds, can it? It seems vague. Imprecise. Arbitrary. Well, yes, in a way it is. That’s what makes relative sizing useful! Here’s an analogy that may help you understand how and why we size user stories with relative

Middleware developers often have a tough time writing clear user stories because unlike consumer software, middleware rarely has clear users. Developers may wind up either using the same vague “API Customer” user repeatedly or dropping the “user” from their stories entirely. But having a meaningful user in mind for stories can prevent a lot of problems. Here are some creative ways to use personas as your users for middleware. The “user” in a user story value statement gives u

As an Agile coach, I’m asked a lot of questions about writing user stories. At the top of the list: "how do I write a good user story?" and "Give me an example of a good user story." That second request is tricky, since what's good for one person might not make sense to another. But I'll tackle the first question here with some examples. First of all, I highly recommend using the "value statement" template to write all user stories, features, and even high-level items like ep