David Ruttka

Engineering | Gaming | Improv | Storytelling | Music

Delivering Value

| Comments

After receiving questions and comments on this post, I’ve started a FAQ to clarify points where I wasn’t clear enough, and rethink points where I didn’t consider all the angles. Please let me know if you have additional feedback on this post.

Activity Versus Impact

…driving toward the true goals of the business

Several years ago, I heard the term Feature Factory, and it changed the way I think about delivering value. I’ve also heard managers encourage me to understand the difference between activity and impact. Picture wheels spinning in the mud. Lots of activity. No forward motion.

Some teams will add features because someone had an idea, and everyone needs to stay busy. There’s a lot of activity in this model, but the team may not be driving toward the true goals of the business.

Other teams will add value, focusing on desired outcomes (objectives, key results, key performance indicators, and any number of other gauges). There’s a lot of impact in this model, and teams will almost certainly deliver what the business needs.

What Do We Want To Do Today

…driving value for the business’s sake, not chasing features for busyness’s sake

When determining what to deliver, I find it helpful to start with why. Determining why we are doing the thing ensures that we’re driving value for the business’s sake, not chasing features for busyness’s sake.

Importantly, we must remain aware that if we cannot understand and communicate why we’d do the work, then going further may not have any value. It may be another wasteful output of an activity-ridden Feature Factory.

Order Versus Priority

…if it’s not a priority, why are we doing it at all

If we only have one idea with clear business value, we can get straight to work. In reality, we’ll end up with a long list of ideas from brainstorming the Why, What, and How. We’ll need to determine the relative impact against these opportunities. Business development is a little outside of my wheelhouse, but in terms of executing on requirements, I can say that order has been much more useful than priority.

I typically see four or five Priority buckets, but if it’s not a priority, then why are we doing it at all? So, we end up with a lot of items marked as a top priority, and we still have to determine the relative value within that bucket. We define Severity or add Milestone tags to help, but we still have many items with the same markers.

Allow me to present the deep magic of determining Order instead of Priority. Imagine that we’re shipping tommorrow, like it or not.

  • Which of the outstanding stories do we wish had gotten done last sprint?
  • Which bug is most damaging to the user, or embarassing to the team?
  • What contractual or legal ramifications come into play?
  • Is there tech debt that, if we had paid it down last month, we’d be better set to execute on all of the above?
  • Are there items we want to put in front of testers or customers sooner, for earlier feedback or to build good faith?

By asking ourselves these questions, we can determine whether each deliverable should come Now, Next, or Later. Better yet, there’s no need to rank all of the Laters… too much will change by the time we get to them anyway.

Staying Objective

What is the next thing the business needs, which is not already in progress?

Everything above helps us determine what is impactful to the business. What follows has helped my teams to execute efficiently to continuously and consistently deliver that value.

We’ve touched on Why, What, How, and When. Regarding Who, assigning work, we can save a lot of time and energy if we embrace uncertainty and start with what we can prove:

  1. We can prove that work items exist
  2. We can prove that we established a desired order of delivery relative to business impact
  3. We can prove whether a work item is done, in progress, or not started
  4. We can prove when someone is free to take an item

Everything else changes daily under our feet. If a team encounters a lot of randomization, found work, or other uncertainty, then deciding in advance who will do what is an exercise in futility. We’d do well to choose a queueing system that avoids reshuffling or rebalancing. So let’s think again about airline check-in versus grocer check-out.

If a person checking in for their flight argues for 10 minutes about their seat upgrade, anyone other than that person and their agent hardly notices. The other agents continue to process all other customers in order, always calling for the next in line. Compare this to what happens when someone at the grocery store argues over a price check.

By deferring assignment until work begins, we also capture a clear signal on our board. What is the next thing the business needs, which is not already in progress? This should be provable, but if work is assigned before it begins, we’ve introduced the cost of ambiguity with no benefit in return. That ambiguity begets additional wasteful communication as we attempt to unwind the stack of inaccurate predictions.

Deferring assigment also allows us to go with the flow of dynamic business demands.. Much like a frequent flier with elite status, we may find new work or encounter an emergency that must be taken ASAP. If we haven’t pre-assigned future work, then the only adjustment we need to make is to put that work item on the top of our ordered list. On the other hand, if we have pre-assigned work, we need to recalculate what can be taken off of whom.

A very similar principle applies to team dynamics. When people join the team, get sick, or move on, we’ll only need to reshuffle if we chose to play a guessing game that we know we’re destined to lose. If we stay grounded in the reality of what we can prove, the system becomes a self-working magic trick.

Wibbly-Wobbly, Timey-Wimey Stuff

The further out, the more time for something to disrupt it, the lower the confidence.

But, Dave!, I need to tell people when to expect these deliverables!”

Great! As above, let’s start with what we can prove.

  1. We can prove how much value the team added in the previous sprint(s)

And that’s it. That’s all we can prove. Anything that isn’t done yet is subject to someone getting sick, to a dependency not coming through, to a bug being more mysterious than anyone could have known, or to found work and emergencies preempting it. Making guesses toward which individual will pick up a work item doesn’t help us avoid any of that.

So, are story points useful for predicting when work might be done? Yes! But only as a prediction, and only as a relative measure of complexity and velocity compared against historical evidence of team throughput. If we’re using story points to determine how much to pre-assign to a given individual, we’re going to have a bad time rebalancing things halfway through the sprint.

When we do have concrete data that the team trends toward 50 story points per sprint, then we can give stakeholders a rough feel for when work will come in. Since we’re looking at the team, not at each individual, disruptions and variations tend to even out. If there are 128 story points ahead of Item X, then Item X is likely to come in after 128/50 = the third sprint from now.

But note, in my opinion, it’s still best to answer in terms of “Now, Next, or Later” for as long as possible. The further out, the more time for something to disrupt it, the lower the confidence. The good news is, when the disruption comes, it’s a blip on the board that most people won’t even notice. Everyone keeps working the same:

Free Dev: What’s the next thing the business needs that isn’t in progress yet?

The Board: It’s right there on the top, unassigned.

Free Dev: Great, I’ll get right on it.