Shared Understanding
A constant challenge when starting to build a view of your value delivery pipeline is the argument over what constitutes a 'Feature', a 'Story' or a 'Task'. Sometimes, even the use of these terms can be contentious, let alone figuring out the appropriate things to represent at various levels.
Now to help make things a little easier, the first tip is this: Don't worry about what is 'right or wrong'. Themes, Features, Stories, Tasks, Sub-tasks and many other terms may be thrown around depending on your organisation, what frameworks and tools you're using, or even just the opinions of the people in the room. Everyone is going to have something slightly different to say. The primary value of shared language like this is precisely that. It's shared. It's less important that you are "right "about what is what, and more important that everyone is using the same terminology.
Agreement on the use of these terms makes it much easier to talk about, represent, and break down work so we can continue to deliver value. What even is a feature? That said, they aren't entirely arbitrary. The concept of user stories and features are designed for a specific purpose: To change the way we think about our work from 'stuff we are doing' into 'value we are delivering'. This can sometimes require a big shift in our thinking as we're so used to trying to track, report progress against, and define success as, what 'work' we've done, but of course 'work' in a vacuum is meaningless. Endless code commits don't necessarily equate to customer value, which is the thing we're trying to maximize.
The first thing to know is we want (where possible) to start at the high level and work down. This is a mechanism to take our pieces of customer value, which often start big, and break them down into smaller pieces in a way that constantly focuses on value delivered.
But nothing will move! Now this is where I often encounter the first protests. "But we're working on big things that take months to deliver something to our customer, this makes it looks like we aren't doing anything!" and the answer is "Yeah, that's sort of the point!". You see, the next most valuable reason to use this mechanism is to shine a light on bottlenecks to value delivery. We all know that our teams are working hard, but these concepts aren't about representing hard work, they are about representing value delivery. If our pieces of work are so big that we can't deliver value quickly, that's exactly the bottleneck we need to address! This opens the question "How do we break the work into smaller pieces?" We shouldn't shy away from that reality. It's not to condemn teams that they can't deliver features or stories in a sprint. That's the reality of most teams work through most of history, which is exactly why this approach is new and exciting! So the dysfunction to watch out for is simply converting our existing 'tasks' or 'project deliverables' into things called features and stories. These aren't just buckets for existing tasks, it's a way to change those tasks into something that solves a new problem. Now what?
So hopefully we now have a better understanding of why and where these concepts become useful, but how do we get this right? (Now this is all just going to be some rough guidance, and you should tweak it for your context and include others in the decision)
The first thing is, we want (where possible) to start at the high level and work down. This is a mechanism to take our pieces of customer value, which often start big, and break them down into smaller pieces that still represent value, rather than just being work packets. So, we usually start with something like the Epic Epic The epic is the biggest piece. A broad idea or outcome that encompasses many streams of work, teams, customers and perhaps many months or years. These are something you're not likely to complete in any one planning horizon, and may not even be something you could complete. However, We don't want these being so vague as to be unhelpful, so try to find a way to articulate who it's for and why it's needed. Some more detailed guidance can be found here.
Epics can then be broken down into 'features'. Feature
The feature becomes our first attempt to break down our larger initiatives into a smaller piece of customer value. In terms if size, you'd normally expect these to be bigger than any single sprint, but not so big as to completely span multiple planning horizons (for instance, SAFe program increments).
These are features of our products and services with significant value to customers. The thing to keep in mind is that if it cannot be consumed by a customer, it probably isn't a feature. The customer might be internal or external, a large or small group, but they should be a person who gets value from its use.
Features are distinct from User Stories, which are our smallest unit of value, because they contain multiple potential pieces of value, that once again, don't all need to be achieved. If we deliver some, but not others, our customers should still receive some value.
User Story
User stories are a little more commonly understood, and there's a lot of good reading out there on how to structure and create them, so i'll skip that part and get to the what matters in this context: A user story should represent the smallest slice of user value. It should be useful to a customer, but unlike a feature it cannot be 'part' finished and still be useful. Since it's the smallest slice of value, (vertical slice, MVP, etc), an unfinished story provides no value. We would never aim to start a story without the intent to finish, and so these become the units that we bring into our sprints so we have an outcome to work toward. anything smaller that doesn't deliver value is a task.
Tasks
Tasks are simple. These are all the things we need to do in order to deliver a story. writing code, running tests, doing research, even delivering smaller but non-valuable (from a customer perspective) pieces of the work. This is whatever the team needs to represent to help them deliver their stories. We generally don't measure these or make them too visible, because they aren't valuable on their own. We don't want to maximize the delivery of tasks, but the delivery of stories (and eventually, features), so we don't want the team stressing over what's here. It's just to help them plan.
Okay, are we still awake? I know, that's a lot to take in, but hopefully this has started to click. Our goal here is to have a mechanism to maximize value delivery, understand bottlenecks, and open conversations of where we can improve flow. The first, and most valuable thing an approach like this can achieve is in shining a light on the reality that our current view of the work is either broken down too early into 'non-value' chunks, or that our pieces of work are simply too big. If this process makes it hard because it feels like we're not 'making progress' or the team is 'doing lots of work that we aren't representing', then congratulations, you've achieved step one. You're understanding your bottleneck. The next question should not be "how do we represent the work we're doing so things look like they're flowing", but rather "How do we change the work we're doing so value flows more quickly. That won't be an admin task. It won't be about how we represent work or what we call it. It will require a drastic re-think of how work enters our system, how we break it down, and how we organize our teams around it.
That's the fun part, so stay tuned for the next post where we might dive into that in more detail!
Comentários