Take a More Expansive View of What Product Backlog Refinement Can Be

There’s an opportunity I’ve seen with many Scrum teams I’ve worked with – the opportunity to take a wider, more expansive view during Product Backlog Refinement (PBR)[1].

The scenes are familiar: teams focusing on one Product Backlog Item (PBI) at a time, building up just enough knowledge about the PBI to estimate its size, estimating the PBI, then moving to the next one – all in a rather rote, mechanical way.

Sometimes this scene is accompanied by otherwise good behavior – like focusing on the top of the Product Backlog and working down, making sure the team has the most knowledge about the work that is most imminent, going after what I call “just in time understanding.”  But there’s still a certain je ne sais quoi missing related to bigger picture concerns and longer-term strategy.

I recently spoke to a security expert who was concerned about his professed “inability for Scrum to handle far-reaching, strategic, cross-cutting concerns like application threat modeling and security.”  Not coincidentally, when asked he described the Product Backlog Refinement sessions he was involved in as above – item by item, tactically focused, and little room for conversation outside of getting enough information to estimate the item.

I’ve also spoken to many an architect, UX designer, and technical writer who profess similar concerns.  The long-term view of their craft – overarching architectural principles, cohesive visual design, consistent voice in text – seems to be slipping through the cracks.

Initially I was confused, to the point of being almost dismissive: “That’s what Product Backlog Refinement is for.”  While that’s true, it’s not very helpful for a practitioner who’s never seen or used refinement as anything other than the tactically focused process described above.

I’d like to provide some solutions and real-world examples to help you use Product Backlog Refinement to solve the sort of problems with long-term, strategic concerns described above.  Everything I’ll describe follows my mantra, “Take a more expansive view of what Product Backlog Refinement can be.”

Here are some simple things you can start doing today to help your Product Backlog Refinement sessions become more strategically focused:

  • Help architects, designers, security folks, etc. integrate and feel like part of your team – start simply by making sure these folks are invited to your PBR sessions. Then, make sure there’s space for them to collaborate and contribute.
  • Make sure you have access to whiteboard space (physical or virtual) during your PBR sessions, and encourage anyone and everyone to start drawing and diagramming when appropriate. For example, when someone is describing an architecture, encourage them to visualize it for all to see and to annotate it with the PBIs they think are relevant.  Screenshots or digital photographs of these drawings can be attached to the appropriate PBIs.
  • At least once every PBR session, step back from the details and ask simple, powerful questions that reframe the conversation a level up from where it currently is.
    • “How does all of this relate to our application architecture?”
    • “What’s slipping through the cracks with the current focus of our conversation?”
    • “How do all the individual PBIs we’ve discussed today relate to each other? Should they relate to each other somehow?”
    • “How does this fit in to our overall visual design?”
    • “What’s making you nervous or keeping you up at night?”
    • “How does this work relate to the Product Owner’s vision?”
    • “What would our CTO and/or CIO want to know about this work? Could we describe it at a higher level using accessible vocabulary?”
  • Invite others outside the team, especially customers and Subject Matter Experts (SMEs), to PBR sessions. This might force some of your PBR sessions to be less freeform and more guided by an agenda (“Let’s bring Sally in on Tuesday because we’ll be talking invoices and accounts receivable”) – so use this judiciously and make sure there’s space in other PBR sessions for freeform, just-in-time discussions.
  • Be open to facilitation techniques from other disciplines – for example, role playing with CRC cards to understand object design (https://people.cs.pitt.edu/~chang/231/5spec/CRCcard/Biddle-Roleplay.pdf), affinity diagramming from the UX community (see the excellent Universal Methods of Design, https://www.amazon.com/gp/product/B007WRCRH8), etc.
  • Get outside the office / virtual meeting! I bet you weren’t considering something like hitting the streets to do live user interviews as Product Backlog Refinement.  But from a Scrum point of view, that’s exactly what it is – the team building up a shared understanding about the work they’re doing.  If Scrum and agile is supposed to bring us closer to the customer, why would you be surprised that we’d physically do that in a Scrum activity?

With techniques like these (and others you discover yourself), I hope your teams develop an instinctual response to the perennial “Scrum doesn’t have a way to handle [x]!!” claims – with the simple but effective, “sounds like a great topic for our next Product Backlog Refinement session – let’s figure it out then!”

[1] Product Backlog Refinement was formerly called Grooming or Product Backlog Grooming – all these terms are synonyms

On Cross-Functional Teams Held Accountable as a Unit

A common problem I see companies – both old and new to Scrum – face is an understanding and execution on the idea of cross-functional teams, and the associated idea of holding a team, not individuals, accountable as a unit.  Struggles in this area commonly lead to:

  • Individuals remaining highly specialized, often identifying themselves as their role (“I’m a tester, so I [should do x] and not [do y]”), instead of as a team member.  This problem is even worse if this is how they are incentivized (e.g., coders are rewarded for slinging code, not for making sure done, quality software is releasable as soon as possible, testers are rewareded for finding bugs, etc.).
  • Sprints looking like miniature versions of a waterfall project – do some design first, then code, oh, and the testers obviously couldn’t do anything until the coders are done…
  • These first two naturally lead to activities with heavy phase gating, where “throw it over the wall” is the method of (non-)communication between gates.
  • Teams remaining in a lot of wait states, because they’re waiting for [specialty x] to handle [job y], because they’re “obviously” the only one qualified (or even worse, “authorized”) to do that.  Oh, and since the specialties are so strictly defined, it doesn’t make sense to pair up to tackle a problem.  For example, “As a coder, I can’t start working on this bug until the analyst has told me exactly how to reproduce it.”

By contrast, where I’m working with a team that is effective as a unit here are some of the ideas and activities I see:

  • Individuals are respected for their specialties, but they are also expected to go beyond their comfort zones.  They identify as team members, and are willing to do what it takes for the team succeed – whatever that might be.  Yes, a coder might help with testing, and a database specialist might proofread the technical writer’s copy.  And yes, that happens even if their individual functional managers are obsessed with “correct utilization” – because that’s what the team needs at the moment.  Ultimately, stakeholders want working software (not “done but not tested” or “done but not ‘done done'” stuff).  That may or (usually) may not have anything to do with some line manager’s idea of “correct utilization.”

Even Alex Rodriguez, generally accepted as one of the most selfish and detached baseball players of all time, “contributed where needed” by moving from Shortstop to Third Baseman…

CC BY-SA 2.0 - Keith Allison - https://www.flickr.com/photos/keithallison/ Here’s a little story to demonstrate this principle.  Even Alex Rodriguez, generally accepted as one of the most selfish and detached baseball players of all time, “contributed where needed” by moving from Shortstop to Third Baseman when he was acquired by the Yankees, where Derek Jeter was already established as Shortstop and team captain.  “Correct utilization” in Rodriguez’ case could have looked like, “the money spent on Alex must go towards his contributions as a Shortstop, because that clearly is his best / most experience-backed defensive position…so if we don’t have a need for a Shortstop, it’s not the best use of our money, so don’t acquire him.”  I’m guessing Yankees fans were pretty happy that wasn’t the rationale and allocation / utilization strategy that was actually used.

Did the Yankees expect Rodriguez to be the best Third Baseman ever?  Better at Third Base than at Shortstop?  More comfortable there?  I hope not, at least not initially.  Third Base is about playing the “hot corner” of sharply hit balls (hand speed), long throws to first, and knowing when to bare-hand slow-rolling grounders.  Shortstop is about range, leadership, and working in tandem with the Second Baseman.  But whatever his shortcomings may have been at his new position, they knew that having him playing at a less-than-ideal defensive position was better for the system (which would include offense, not just defense) than not having him at all.

  • The diminished focus on specialist roles allows more natural interaction between the different specialists, where testing informs coding, coding informs architecture, architecture informs testing, testing informs analysis, etc. – any and all possible permutations.  There is no waterfall of phase-gated activities – there are the right interactions at the right times with the right sequence – where “right” is determined empirically by the people closest to the work, not by a process or dictate.  This is how software is actually built in the real world, even if you pretend to have strict phase gates – the difference here is we’re going to acknowledge and optimize for that, instead of insisting that separation exists and treating any lack of separation or any need to iterate back over ideas as “problems.”
  • With more natural interaction between specialties, the “throw it over the wall” and “not my problem” phenomenon start to fade away.  Where there were things that were treated like strict, detached handoffs in the past, we now see at the very least informative walkthroughs between specialties, if not outright collaboration in building the artifacts at hand.
  • This sort of collaboration – pairing, swarming, mobbing – eliminates handoffs, because multiple people have their hands on something at once.  There are far fewer wait states, because the team as a whole relentlessly focuses on the most important work at hand.  No analyst available?  What can we learn on our own to start?  Who can we talk to?  How can we leverage the inherent low risk of our small batch (determined by Sprint length) to do something that makes a reasonable amount of sense, even though we still wish we had someone with this specialty around?  Asking these questions become both a cause and an effect of a team who feels empowered, motivated, and accountable.
  • Team members start to realize that underneath, they’re all doing the same thing – discovery, experimentation, and building something to satifsy users.  Designing the right architecture involves understanding the user’s needs and the product’s vision (Architect <-> BA <-> PO).  Coding is judged by whether it works and whether it solves the user’s problem – i.e., the cornerstones of testing, verification and validation (Programmer <-> Tester <-> BA <-> PO).  Good architectures allow for the testing of the most granular structures to the most coarse (Architect <-> Programmer <-> Tester).  Test cases start out very abstract and declarative, and move towards detail and imperativeness – just like the implementation of a feature in code itself (Tester <-> Programmer). We’re not only on the same team, we’re all doing the same thing.  Our specialties are merely dimensional views of the same thing, with the same goals.  We have more in common than we do in difference.  We are discovering, experimenting, and building valuable, high-quality solutions to delight users.  All of us.  Together.

We’re not only on the same team, we’re all doing the same thing.  Our specialties are merely dimensional views of the same thing, with the same goals.  We have more in common than we do in difference.  We are discovering, experimenting, and building valuable, high-quality solutions to delight users.  All of us.  Together.

Again, the value or breakthrough here isn’t that idea itself, because that’s always been true – the value and difference is acknowledging and optimizing for that fact, instead of pretending it’s not true.

In the future, I plan on writing some posts that talk about specific, detailed expectations that can be set for team members, regardless of specialty, and the sort of behaviors that these expectations engender.  Stay tuned…

The Sprint Burndown – WHY? Part II

This series will talk about the WHYs behind a commonly used, misused, and abused concept in Scrum: the Sprint Burndown. A Release Burndown is an entirely different thing, with different goals and a different audience, which these posts will not cover at all. The confusion between these two burndowns, especially understanding the different audiences, is one thing that leads to misuse of the Sprint Burndown.

Last time, we talked about the basics and the core why behind the Sprint Burndown. Now, let’s talk about the Sprint Backlog in more depth, and at the same time move towards the bigger picture of metrics and audience.

This post answers questions like, “Can I, as a manager, use the Sprint Burndown to gauge the performance and progress of the team?”

  • Understand that a burndown is a crude, single metric – so there’s a lot of conversation that needs to come along with it. That is, just having a Sprint Burndown, even if it’s accurate and up-to-date, is rarely enough to-know-where-you-are (see the previous post about why this is an important need). For an example, enter the Daily Scrum – if the SB looks good today, but Jimmy is totally stopped on a huge, key task, for example – the team should hope they’re not just looking at the SB and saying “looks great, moving on…”, and they should hope Jimmy is speaking up (or at the very least, the Scrum Master is helping facilitate that), because things are not “great.” That’s not where they actually are, regardless of what the SB says.
  • That said, the SB is useful all by itself as a trigger for explicit adaptations – “we’re not where we thought we would be, even a crude metric like the Sprint Burndown can show us that – what are we going to do?” If you’re not using it as a trigger to adapt, and just looking at a drift from the ideal trend line and saying things like:

    “Well, maybe it will get better.”

    or

    “Let’s just work harder!”

    or

    “It’s really not that bad, I’m about to close 4 tasks and then the line will go down, trust me…”

    – then I actually recommend you stop using it immediately, because you’re not doing anything with it that’s intended – you’re not really believing it (you might say you’re not actually inspecting it), and most importantly you’re not using it to adapt. You’re wasting your time, and you or someone else is likely drawing conclusions from it that are very dangerous because they’re so detached from reality.

  • This “problem” (it really isn’t a problem, it’s just the nature of the thing) – that the SB isn’t all that useful by itself, other than as a trigger for more granular discussions around adaptations made in response to its inspection – is much greater, with even more implications for the outside (of the team) observer of the SB. Anyone outside of the team should be very careful about drawing any conclusions without additional information from the entire team. “Don’t draw sweeping conclusions from isolated metrics,” is one cliche that applies here. You can probably start to guess where I’m taking this…
  • The SB, when used, or any other how used to meet need-to-know-where-we-are, is explicitly for the team, as one tool that will help guide them to meeting their Sprint Goal. Outside observers don’t have enough context for it to mean anything of value to them by itself, and for the team to add the context would involve so much time on their part (it would go well beyond just observing the Daily Scrum) that you may as well put the outside observer onto the team – which is impractical for all sorts of reasons, and not what the outside observer is after, anyway. Even so, I oftentimes see managers and others outside of the team trying to use one simple thing, like a Sprint Burndown, to draw conclusions that have nothing to do with what’s being tracked, or the actual goal of the artifact in question.
  • The questions and conclusions I see these outsiders trying to understand – whether the team is successful and performant, whether they need help and what kind of help, whether medium- or long-term goals are in jeopardy, whether we’re happy with the return on investment of this team in the context of building this product – are all very good things which I encourage you and them to understand. A Sprint Burndown, quite literally, tells you none of these things. Let me repeat:

    A Sprint Burndown, quite literally, tells you none of these things.

    Trying to use it for these means will be very frustrating for people outside of the team, because it just won’t work. Trying to use it for these means will be very frustrating for people on the team, because that inevitably comes across as (and most often actually is) micromanagement.

OK, so I’ve said that the SB is not the tool for understanding these things, but also that these things are still valuable – so, what are some good tools to understand these things?

Next time we’ll talk about the answer to that question, which will also actually help us understand more about the Sprint Burndown.

The Sprint Burndown – WHY? Part I

This series will talk about the WHYs behind a commonly used, misused, and abused concept in Scrum: the Sprint Burndown. A Release Burndown is an entirely different thing, with different goals and a different audience, which these posts will not cover at all. The confusion between these two burndowns, especially understanding the different audiences, is one thing that leads to misuse of the Sprint Burndown.

Let’s start with the basics.

This post answers questions like, “I feel like the Sprint Burndown is a waste of time – we don’t use it for much – can’t I just stop using it?” and “If this is all about remaining work, where do I track the hours I actually worked today?”

    • A Scrum Team needs a way to understand where they are in relation to their Sprint Goal and the work they forecasted for the Sprint (what’s on the Sprint Backlog), at any and all times during a Sprint.

 

    • Without this transparency, there is no opportunity for valid inspection, and therefore no opportunity to successfully adapt. There’s a reason the team meets at least once a day, in the Daily Scrum, and it is not about individual team member status. It is about understanding where you are as a team, and as a team figuring out what to do next to achieve the Sprint Goal. If where-you-are isn’t where-you-thought-you-might-be, what are you going to do about it? Inspect and adapt, inside a 24-hour window, to get to the right place in the 1 to 4 week window (the Sprint) – that’s what we’re after. Without a transparent sharing and understanding of where you really are, and the ability to respond to inevitable uncertainty even in a window as short as a Sprint, you will never get to where you want to be. All of this is the why behind the expectation in the previous point, and that’s always important (I’ll talk a lot more about this throughout this series of posts, as the title suggests 🙂 ).

 

    • The Sprint Burndown is about tracking only the team’s current understanding of the work remaining, so the members can adapt based on that reality.  It’s about reflecting current learnings and truth of the work in the Sprint, and keeping focus on, “What’s left?  How do we complete this and deliver value?”  The “actual” or “burndown” line of the SB (as opposed to the “ideal trend” line) does not reflect how much work has been done.  Doing work, putting in hours, tracking the hours you worked – those things are somewhat interesting, and you may need to track them (I get it, I’m a consultant), but they have literally nothing to do with the Sprint Burndown.  I may have worked 8 hours on a task I originally thought would take 4 hours, and still have 6 hours left by my current estimation and understanding.  So, “6” goes into the remaining work field of that task (A corollary to this is: a team with burndowns that never burn up, day after day, Sprint after Sprint, is telling itself a lie – building software is in the complex domain, and estimates will inevitably be wrong at times, even in time horizons as short as a Sprint or a task).  The fact that I worked 8 hours might be interesting to a manager or accountant, especially if we’re capitalizing the work I’m doing, but I should completely ignore that in regards to the Sprint Backlog and any tasks contained within.  If you have to track this, I’d strongly recommend you track it in another system to avoid confusion and maintain focus on what each activity and tool is for.

 

    • A Sprint Burndown is a common way in the Scrum world to satisfy this know-where-you-are need – most every tool supports it (not that that makes it a good idea per se, but it does make it easy), and it kinda-sorta-used-to-be an official Scrum Artifact. It is no longer, because an SB is but one way you might achieve the goal – so “knowing where you are” is the expectation, how you do that is up to your team. (That is not the same thing as saying the team could choose not to meet the expectation (and be unable to inspect and adapt inside a 24-hour window), or use something that is not accurate or useful, either – enter a good Scrum Master who can set expectations about what is needed and why, without having to prescribe any particular how.)

 

    • One example of a different how than a Sprint Backlog: some teams size their tasks to be no larger than x (oftentimes, a single day / 6 to 8 hours), and simply use the count of tasks in the Done column vs. the count in the To Do and In Progress columns of a task board to tell them where they are (a simple count drives things, not hours/effort/size as in the y-axis of the most common type of Sprint Burndown). No Burndown is built – just take a quick glance at the board – how does it feel, now that all task post-its are roughly equal? Sure, go ahead and count them if you need to. Good enough. Note that without the explicitly small/bounded task sizing, and instead with a huge range in task sizes, this rarely works – it tells you very little about where you are.

 

    • Another example is using test reports (usually focused on Acceptance Tests) and comparing passing and failing tests – the context with this one is a truly test-driven environment (beyond just unit tests via TDD – thinking about “test-driven” in a holistic, comprehensive way work is approached). This often means there are test(s) for each Acceptance Criteria, shelled out (and initially failing) directly inside of Spring Planning, etc. – in this case, “done” for a Sprint Backlog Item / story is a report where all of its tests are passing (functional side, roughly), and it meets the Definition of Done (non-functional side, roughly). This is an incredible place to be, when an entire team is focused on making something work exactly as the customer is expecting / would accept – and the focus is continuously, relentlessly on that. It helps teams not lose focus on minor technical debates, etc. But I digress.

 

Next time, we’ll talk about the Sprint Backlog in more depth, and at the same time move towards the bigger picture of metrics and audience.