Skip to main content

Author: Robert Galen

Agile is a Team Sport

Written by Robert Galen on . Posted in Articles.

By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.

Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.

It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.

What’s often lost on most organizations and teams is that when you focus on keeping individuals busy and optimize at the functional level, with silos, hand-offs, and dependencies – you go slower. Sure, it feels like everyone is working hard…and they are. But the results, the throughput, the value, is often much slower than it’s agile, collaborative counterpart.

Sidebar

I often try to make this point with my classes, and I’ll share it with you here. Don’t take my word for the above. Instead, run an experiment. Run a sprint the way you normally would do it – without much collaboration. See how many stories you get done. Then take roughly the same story mix and run it focusing on collaboration and swarming. Worry less about keeping everyone busy, but focus on collaboration, swarming, and throughput – getting as much done as possible.

To-date, I’ve never seen a team do less than their waterfall behavior equivalents. If they run an honest experiment, they often get 50% – 100% or even more done by working together. I know, it’s counterintuitive, but please – run the experiment across two sprints.

Then reflect about what’s going on…and try to do more of it.

Distributed Teams

I was talking with a potential client the other day. They had a widely distributed team. Let me describe some of the dynamics:

  • The developers were spread across the country; each in a separate location;
  • The testers were centrally located in a remote office;
  • The Product Owner was in the central office along with the Scrum Master.

They said they were “Agile and doing Scrum” when I spoke to them. But because of the distributed nature of their team, they were skipping some key things. For example, having a daily stand-up was incredibly inconvenient for them. So they skipped it. Instead they sent around status email messages as a way of trying to stay in-synch.

There was no sprint planning or backlog refinement either. Each developer would essentially agree to their specific work and mail in their game plans. It was up to the QA team members to try and figure out how to support each one. Essentially all of the developers were chucking code over the wall to the testers at the end of each sprint and hoping for a miracle.

But the miracle rarely happened and they were struggling with delivery. But guess what else they said?

Bob, clearly agile doesn’t work in a distributed environment. We believe we’re failing because we’ve adopted agile.

I asked them, did you have the same team structure before you adopted agile?

Yes.

Did you have delivery problems before?

Of course, it was worse then. We couldn’t deliver anything on time without killing ourselves at the end. But we thought moving to Agile would fix things.

My Response

I get this pushback all of the time in my agile coaching and training travels. Nearly everyone asks about how agile works in distributed environments. Their challenge is always – that it doesn’t work.

So what does it take to make agility successful in distributed team contexts?

A few things, but one of the keys for distributed teams is COLLABORATION.

You must collaborate as a team – Imagine that!?!

Have you ever heard the expression – “fake it until you make it”? I think it applies to agility as well. Instead of throwing out all of the collaborative goodies because “they’re too hard”, why don’t you pretend you’re agile in the interim. In other words – commit to collaboration! Commit to the principles of self-directed teamwork, accountability, quality, transparency, etc.

And if you’re COMMITTED, then my supposition is that each team will figure out a way to make things work.
What are some of the key aspects of agile collaboration?

  • Meet face-to-face whenever possible – I know, I know, you don’t have the budget for it. Well, plan some budget for it. Teams need to be built and you can’t do everything remotely. Consider flying folks back and forth or consider special events where everyone gets together. If you’re starting a new agile project with a distributed team, one of the best things you can do is get the entire team together to charter or kick-off the project. Allow them to run the first sprint “as if” they were co-located. Let them get a feel for each other and working as a team. I talk about this more in this blog post.
  • Pairing – 3- Amigos – Try to pair (remote pairing) whenever possible – Don’t view it as you’re wasting time; instead consider it an investment in collaboration and teamwork. And I’m not simply talking about developer-to-developer pairing. Testers can pair. Or developers with testers, or you can engage in 3-Amigo style collaboration. The less individual, lone wolf work that is done within your teams the better the collaborative results will be. But don’t force the pairing. It has to come from within each team member and be opportunistic and welcome. But encourage it and don’t “count hours”, but review the results the pairing is driving in productivity AND quality.
  • Daily Stand-up – It’s incredibly important to have a daily synch-point or collaboration event for the team. It sets up a “heart beat” for the team to communicate, share successes and challenges, and to help one another. So no matter how distributed your team is, you need to agree on a mutual time and be there. But not just attend. You need to be engaged in the standup – listening to everyone and fully participating. Remember, you should have committed to the Sprint Goal as a team, not distributed individuals, so you should be interested in every conversation.
  • Co-location – One of the ongoing points that folks with distributed teams make is that they can’t be co-located. And I agree, this is a drag. One of the “sweet spots” of agile teams is the notion of a cross-functional, co-located, self-directed team. So it’s a disadvantage. But it doesn’t have to block all collaboration. Put on your creative “thinking hats” and try ways to setup a virtual, co-located environment. Use web cameras, share whiteboards, use whatever tools you have, and yes, pick up the phone. I’ve found that distributed teams can be incredibly creative in setting up virtual co-located environments that are nearly as good as “being there”. But the rub is, you have to put in the extra effort to do it.
  • Swarming – I’ve worked with a company that has some distributed team members and they constantly push back on swarming their work – preferring that lone individuals work on each story. In fact, if I even mention the word swarming, they become agitated. Imagine how this culture handles more distributed team dynamics? Yes, badly. And their results? Fractured at best. In your sprint planning you’ll want to plan for collaboration wherever possible. I realize it’s hard to swarm around a 1-point user story. So don’t. But what about a 13-point user story? The goal of your sprint execution should be getting each story done (ASAP) instead of keeping individuals busy.
  • Exploratory Testing – Far too many agile teams don’t know about Exploratory Testing. It’s a technique for “exploring” applications as a group and keeping track if your “journey’s and findings”. I like to do it in pairs. Teams carve out some time to test in pairs in time-boxed sessions. Each session has a charter that defines a pair’s area of the application to explore. Then the pair tests within those boundaries for a session – let’s say 90 minutes. At the end of each session time-box, the pair’s get together to debrief their findings, progress, and plan next steps IF they’re going to run another session. Not only is it a wonderful way to attack testing as a whole-team, but it also reinforces pairing and collaboration.
  • Customer Demo – Often we forget that the sprint isn’t “done” until you’ve conducted a sprint demo AND received feedback. And the demo is a whole-team activity, so everyone needs to be there. Heck, forget being there, the team needs to be interactive in presenting their results. Now this can be particularly challenging with distributed team members, but put some creative pressure on yourselves to “figure out” how to get the entire team involved in planning and executing your Sprint Demo.
  • Backlog Refinement & Team-based Planning – It turns out that backlog refinement meetings, ongoing backlog refinement, and sprint planning are FOR the team. They require whole-team engagement. Often this is a contention point in distributed teams because it might be challenging to get everyone together at a “convenient” time. I say tough! These are team-based activities and the team needs to figure out how to get everyone not only attending, but engaged, and working together in the plan and during the execution of each sprint. These meetings are the backbone of your agile results, so they are required.

Leadership Accountability

And focusing on making it a team sport isn’t just – for the team. Organizational leadership must be held accountable for:

  1. In their infinite wisdom setting the organization up in a distributed fashion;
  2. Realizing that it’s less efficient to work in distributed teams; i.e., there will be “drag” and ongoing challenges;
  3. Supporting their teams requests for tools, trips, and anything else that fosters collaboration;
  4. Realizing their responsibility over time is to:
    1. listen to each teams feedback and
    2. reduce the distributed nature of the teams as much as possible.

Over time, try to move the WORK to co-locate TEAMs as much as possible. Even if that means increasing costs in the short term or disrupting strategic plans that were made before the decision to “go Agile”.

I guess what I’m saying is that distributed teams are a CHOICE. And I’ve found that there is tremendous leadership “wiggle room” in reducing the distribution over time.

Wrapping Up

I’ve often found high-performance distributed agile teams. Frequently they kick the butt of their co-located counterparts.

Why? Normally there are two, high-level reasons.

First, the teams commit to agile principles and cross-team collaboration. You could move some of them to the moon and they’d still find a way to make it work in delivering value to their customers.

And second, their leadership teams understand that they’ve setup the teams with a challenge from the get-go, but they do everything in their power to support collaboration within their organization AND to reduce distribution over time.

In other words, they’re creative and committed.

BTW: I like the hockey picture because ice hockey is one of those sports where true teamwork is fostered by up to 2 players gaining assists for someone scoring. Talk about swarming…

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Definition-of-Done – Are We There Yet Part 2

Written by Robert Galen on . Posted in Articles. 1 Comment on Definition-of-Done – Are We There Yet Part 2

This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.

I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.

Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.

But he said something about Definition-of-Done that I challenged and it inspired me to write this “addendum” to my original article. I’m assuming you’ve read that one before this one.

So what bugged me? I’m glad you asked…

Where Does DoD Come From?

In his talk he implied that the team defines their own Definition-of-Done. That they (half jokingly) sequester themselves in a room for a half-day to a day and figure out what done looks like to them.

While I don’t have a problem with the team contributing to the DoD, I do have a problem or concern with the team being the sole arbiter of done-ness. When I asked him about this concern, I used the example of an organization that was creating regulated software. In my example, I said – “what if the team didn’t care to make “traceability” a part of their DoD? Since the business would be literally required to do that to remain solvent, the team would really have to add it whether they agreed to or not – right”?

His response was that agile is about self-directed teams and that we can’t “make” the team define a DoD; instead it has to come from within the team. He implied that there might be another level of approval beyond the team, but he didn’t give any specifics.

I didn’t challenge his answer in the class and the presentation moved on, but I struggled with this view.

Context Does Matter

So to be fair, I guess there are some agile team contexts where having the team solely defined their Definition-of-Done makes sense. I think of many start-ups and very small environments as examples, or teams who are using agile approaches for non-software development.

But there are so many more contexts where organizational constraints need to be “built into” your DoD. I mentioned one of them in my above question.

If you’re working in regulated environments, then tracking test cases to requirements (traceability) is often a very hard requirement. As is running a full regression test as a part of pre-release testing activity.

Another example where I think it makes sense is in larger enterprises or anywhere where you have agile at-scale. For example, I’m aware of one large company that doesn’t provide any constraints at a team level towards Definition-of-Done, tooling, or development practices. None. Every team does virtually whatever they wish and the result is pure chaos. There are no consistent practices, constraints, or even approaches to what agile methods they’ll use.

I apologize in advance if this offends anyone, but this isn’t “Agile”. Everything isn’t optional and the goal is NOT chaos or encouraging the inmates to run the asylum. I think its normal and good practice to provide realistic constraints for mature agile teams.

What IS the “Right” Way?

So Bob, are you saying that the team has no say or input in their Definition-of-Done? Of course not!

But I’m strongly recommending that they don’t have the entire say as well. What I’m looking for is something in between. Where the organization contributes key constraints and goals to the Definition-of-Done. Items relevant in support of the business and economic goals. Then I’m looking for the team to bring their ideas for completeness to the table and meld them into a more unified and balanced DoD.

If you consider my 4-tiered model for done-ness criteria, then some of the tiers have more organizational influence than others. I would expect the release-level to nearly entirely influenced by organizational goals. Conversely, I would expect the work product-level to be mostly owned by the team. The middle two levels should have influence by both sides.

Usually I expect the organization to give the team their input for organizational constraints within the Definition-of-Done. Then, to Jeff’s point, the team should meet and make it their own by adding their own conditions and views. I think this approach creates a balanced DoD, where the team had a chance to weigh-in and create shared ownership.

DoD has a “Cost”

There’s also one other point I’d like to make that I didn’t emphasize in the original article and it supports this argument. I firmly believe that Definition-of-Done has a cost and minimally has to be negotiated with and agreed with the business. In other words, a team can’t simply decide on what’s in vs. out in their done-ness.

The primary negotiating voice for the business and customer is the Product Owner. But in larger scale organizations, the individual Product Owners need to balance things from an organizational perspective. For example, a team might want to build automation as part of each and every user story; so they put it in the DoD. I personally like that goal being a part of things and think it indicates a more mature view to full feature delivery.

That being said, the Product Owner needs to “buy” it, as this constraint has a cost. So there needs to be some healthy discussion and negotiation around many of the constraints within typical Definition-of-Done’s. Some things are non-negotiable, while many others are—depending on their cost.

Wrapping Up

Going back to Jeff’s presentation, clearly his organization is one where the teams defined DoD. The question I’d ask them – is the DoD balanced and does it contain organizational constraints towards quality, the customer, and release? If the answer is yes, then I think their approach is fine. If however, the team has ignored some important organizational constraints and “punted them” downstream for accountability, then I have a problem with that.

And remember, this is as much of an organizational problem as it is a team problem. I think it’s easier for many organizations to not communicate key DoD constraints to their teams in order to avoid conflict or the appearance of being “non-Agile”.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Definition-of-Done – Are We There Yet? Part-1

Written by Robert Galen on . Posted in Articles.

Introduction

There are several terms used for it within agile contexts. Sometimes you hear:

  • Done
  • Definition-of-Done or DoD
  • Done-Ness Criteria
  • Acceptance Criteria
  • Release Criteria

Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.

Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.

Done-Ness

Consider done-ness to be the criteria that constrains the teams’ work. If the team were building a bridge, then it would be the engineering rules, practices, inspection steps, local regulations, and completion requirements that would permeate everything the construction team would do. In many ways, the Definition-of-Done should seep into every aspect of agile team collaboration. If agile were a game then DoD would be the “rules” of the game…and the rules would be read, understood, and consistently applied across the team.

I’ve always been a strong proponent of a 4-layer view to done-ness. In this worldview, the layers build upon one another, moving from individual-based work, to story-based word, to sprint-level work, and ultimately to a release. I’ll often use the term “guardrails” to indicate the guideline nature of the criteria in guiding the teams’ efforts. Now let’s review each of the four levels in turn.

Work Product

This is the layer of the individual contributor. For example, your front-end developers should define some rules, conventions, and standards for how they design, develop, test, and deliver their UI code. The adherence to these standards should be defined specifically as done-ness criteria. This same logic applies to each functional role within your agile teams. Everyone should define a set of criteria that surrounds professional delivery of their work products.

  • Who contributes these? Usually there are two sources. Probably the most powerful is each team defining its own engineering rules. So there is a strong sense of uniqueness as you move from team to team. The other source is more organizational. Say for instance you’re working at a large web design shop where there needs to be consistent UI coding conventions and standards across the teams. I would expect “someone” in the organization to define these—and then for each team to adhere to these broader done-ness criteria in addition to their own.
  • Some examples: I literally gave one above, in that you might have UI development standards. Another example could be coding standards for you primary language or technology stack. Still another could be process based, for example, an “agreement” at a team level to try to “pair” as much as possible on each user story OR to have a “pair review” prior to checking in each story.

Story Level

This is the work delivery level. If you are using user stories, then done-ness surrounds defining a rich and meaningful set of acceptance tests per story and then holding yourself accountable to delivering to those functional constraints. Remember, acceptance tests are incredibly useful as design aids and test aids when the team is sorting out the nuance of each story. I consider that the most important part of the acceptance tests—the business logic design hints.

You should also develop clear quality goals at this level. It may sound prescriptive, but I like the criteria that all bugs that have been found in the development of a story to be fixed prior to declaring that story complete. These aren’t legacy bugs, but bugs created and found during the development of the story. I can’t tell you how many times teams run into problems at the end of the sprint in delivering a completed story with no known bugs.

  • Who contributes these? The Product Owner is ultimately responsible for defining the functional conditions of acceptance for each story. However, there are also inputs from the organizational side. For example, agreeing that each story will receive a solid pair-based code review or that a complete set of automated unit tests (TDD) will be developed and running before checking in and “declaring victory” might be decided as overall quality criteria that impacts every team.
  • Some examples: I gave several above. Clearly the story has to meet the Product Owners established acceptance criteria. I also like the notion of the Product Owner signing off on each story. That is, they review it, demo it, and determine that it is indeed—done. Then they physically sign-off on the story. Usually story done-ness also surrounds the design integrity, process steps to develop and test the story, and known bugs.

Sprint-Level Criteria or Sprint Goal(s)

This level is focused towards how well the team has met all of the goals and criteria they set forth when the planned their sprint. A large part of these criteria are typically driven by a successful sprint review or demo. I like the notion of “connecting the dots” between the sprint goal and the sprint review, so the team should think about the goal as a cohesive demonstration of business value from the customers’ point of view.

In my classes I often get asked, can a sprint have multiple goals, i.e. deliver on multiply focused activities? The answer is probably yes, but what the question is really looking for is the ability to say:

The goal of this sprint is to deliver 524 hours of work towards these specific 12 User Stories that are sized at 27 Story Points.

I think this is an incredibly poor goal because of the tactical, work effort focus. For example, there is no “customer” or no “demo description” in this goal. I’d much prefer goals that have a clear connection to the customer, value, and their challenges embedded within the goal. Having 2-3 separate goals articulated in this way seems fine too.

  • Who contributes these? Truly it’s the responsibility of the Product Owner to define or establish a goal for each sprint. I usually encourage them to bring a tentative sprint goal into sprint planning and then align that with the team and the agreed sprint work as part of the sprint-planning meeting. It then becomes a shared and achievable goal.
  • Some examples: If, for example a team were working on an ATM project, then a few related sprint goals might include: Complete single customer sign-on and account interrogation to include balance and transaction lists for the past month. Another one might be: Complete and demonstrate all deposit based activity (single/multi/business) account transactions with receipt printing. Only check deposits will be supported. I hope you see the connection to real-world customer usage scenarios. I’ve found these goals, which have open-ended functional details, to best inspire the team to “solve a problem” versus “deliver a set of stories”.

Release-Level Criteria or Release Goal(s)

If you’ve ever been part of a team that delivered software in more waterfall environments, a common practice is to create release criteria. These are project constraints requirements that are usually established at the beginning or early on in a project. Often they are consistent from project to project or release to release, because they quantify organizationally important criteria. For example, quantifying whether you could release with specific levels of bugs (both in priority and count) or quantifying how much testing (coverage) needed to occur prior to a release.

One of the unfortunate parts of many agile adoptions is that these sorts of criteria have been dropped. I think they’re incredibly valuable in defining meta-requirements or key constraints for the teams to adhere to within each release. Typically they exist anyway within the organization, but calling them out creates a focus on them in planning, execution, and delivery. They’re particularly important in at-scale delivery—so that multiple teams are maintaining a consistent focus on their overall release goals.

  • Who contributes these? Usually they’re defined outside of the team proper. Either being defined by the Product Ownership team or Chief Product Owner as part of establishing the definition of a release. As I mentioned, they often carry-over from release to release. They are typically “not optional”, so the organization needs to be willing to block a release or drop a feature if it does not meet the release goals.
  • Some examples: I’ve already mentioned allowable defects in the release and test coverage as solid examples. Global performance targets or usability constraints are often mentioned in applicable projects—so there is often a focus on non-functional requirements. Process constraints or commitments might also be mentioned, for example, the fact that each user story needs a minimum of 70% automated test coverage before being considered a candidate for your release train.

Getting Done-Ness into your DNA

Creating a list of your Done-Ness Criteria is only the first step. Just because you have created and communicated them, doesn’t mean that everyone is supporting them. The next step is establishing a culture where everyone aligns with and personally supports the criteria. Not just when things are going smoothly, but when the going gets tough as well.

You know that your done-ness has seeped into your culture when the team sees no other recourse but to do things the right way. I’ll share this example from my time leading teams at iContact that illustrates this cultural transformation:

We were a SaaS e-mail marketing software product and our customers used us 7×24. In fact, our weekends were often quite busy as SMB owners worked on their next week email campaigns. There was one weekend where a nasty mail sending component bug cropped up. It brought down our ability to send email, which clearly affected all of our clients. Not only that, when this happened, we would queue the mail. So this started created an endlessly increasing pool of mail that would cause delays even when we fixed the bug.
So the pressure was on.
Our teams would normally assign a “support engineer” for weekend support. The engineer in this case was notified of the problem, looked into it, and devised a repair. As part of our DoD, we’d agreed that no fix or repair could be checked-in without a paired code review. Now keep in mind—this was a holiday weekend, so people were on vacation. The support engineer determined that he needed a review with two others who were experienced in this area of the mail-sending stack.
He found them via text messages and phone calls and they all committed to a distributed/remote code review session on Saturday afternoon. They discussed a few issues and changes related to the repair, and then he completed those adjustments and released the repair.
When I came in on Monday morning I was amazed at how committed the team was to doing a proper review. It would have been the easiest thing in the world to have either checked-in an un-reviewed repair OR waited until everyone was back on Monday. But the support engineer and their teammates were committed to our customers and to their Definition-of-Done. It was in their DNA.

Why Done?

So after all this discussion, you might be asking yourself – why all of this focus on done? Why does it matter?

It matters from several perspectives:

  • It helps with your estimates. Pre-agile methods, I’ve used done-ness like criteria in my teams because I felt that if we didn’t have clarity around what went into completing our work, how could we estimate our work. That’s the very point we’re focusing on here. Clear understanding of what is expected in completing our work.
  • It helps with your quality. It provides guidance to the team surrounding what makes each step or deliverable complete. It focused on quality of the steps. And it amplifies consistency – so that every check-in or deliverable meets a consistent level of completeness.
  • It helps your Product Owner and customer gain confidence as the team delivers. And it’s not just confidence on the individual stories. It’s confidence on the overall plans and teams ability to meet their commitments with consistent quality.

Is it a panacea for any of the above? Of course not! But it is a key driver for some of the core behaviors that agile tries to amplify in teams. That’s why you hear so many agile coaches “harping” on it.

Wrapping Up

I often emphasize Done-Ness as a place for the organizations leadership team to influence the behavior, focus, and results of their agile teams. I encourage them to get engaged with establishing a deep, broad, and relevant set of criteria for their teams. I ask them to align their DoD to the business, customer, and constraints. I sometimes call them “guardrails” because of my view that they can keep the team “safely on the road” in their delivery of business value and results.

Since I see so many sparsely defined DoD’s it the real world, I usually ask for organizations and teams to over define them – risking a bit of prescriptiveness. I’d rather have more clarity than less guiding the teams.

Hopefully this article has helped clarify a view to what done looks like in agile teams. Now go take a look at your own Definition-of-Done and see if you need any adjustments?

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References

Capacity Planning for a Balanced Backlog

Written by Robert Galen on . Posted in Articles.

galen Feb10

Todd Olson was the VP of Products at Rally Software for a few years. I met Todd when he was the co-founder of 6th Sense Analytics here in the Raleigh-Durham area. Todd’s background is mostly as a software engineer, but after Rally acquired 6th Sense, he developed a wonderful sense for product evolution and management as well.

Not that long ago, Todd made a presentation at our local Agile Leadership Network group. It was entitled: Curing Feature-itis and it focused on the balancing act associated with planning a balanced agile portfolio.

In this article, I want to bring that discussion down to the Product Backlog level and discuss some of the aspects and techniques associated with keeping your backlogs healthily balanced.

Feature-Feature-Feature (Feature3) Syndrome

When I saw the topic of Todd’s talk, it immediately resonated with my own experience. I’ve often used a term to describe a common anti-pattern that I frequently see in many Product Backlogs. I call it—Feature-feature-feature Syndrome. It implies that all of the stories (or items) in the backlog are customer-facing features—100% of them. It also implies that the backlog is incredibly imbalanced.

What’s the cause?

Well, I’m glad you asked.

One cause is the consistent business pressure that every Product Owner is under, or at least every PO that I’ve ever met. One consistency in today’s software organizations seems to be that there is always more work than there is staff (capacity) to deliver it. And this pressure lands squarely on the lap of the Product Organization and the individual Product Owners.

I’m not saying this is good or bad—it simply is.

In the Scrum model, it falls to the Product Owner to “manage” the Product Backlog. Inherently they are empowered to and responsible for what goes onto it. But when the feature pressure is on, many succumb to it and only put stakeholder or customer facing features on the backlog.

Which isn’t necessarily bad for short-term bursts of activity, but for longer-term product viability, it can be an incredibly short-sited strategy.

So what is a “balanced” backlog?

Again, good question. And the consultant in me wants to answer with – “it depends”.

Seriously though, I think the answer can be somewhat clearer. A product backlog needs to contain all of the work required to create a product or project for a client. It certainly must contain software features or functional user stories – ones that are demonstrable, otherwise, what would be the point?

But there are things in products beyond the features themselves, for example, infrastructure development, architectural work, and testing activity supporting regulatory concerns. Here’s a more complete list of some of the components of a more balanced backlog:

  • Development Infrastructure
  • Testing Infrastructure
  • Test Automation
  • Testing Environments & Data support
  • User Story – Research Spikes
  • Architectural Look-ahead or Runway activity
  • Design activity
  • Bug fixes (from longer term defect backlogs)
  • UX Design
  • Time for Testing Traceability
  • UAT at a system or product level

All things that I might want to capture on, and prioritize against features in a backlog. By reserving stories on your backlog, you reserve time for this important supporting work and make it transparent.

And these items, instead of coming from the stakeholders or customers, typically come from the team. In this view, the Product Owner is taking in feedback from all constituents and trying to do their best job of listening and ordering the backlog.

Who’s the boss?

Another thing to consider in your balancing act is that the customer isn’t always the boss of you. Yes in agile teams you need to drive towards delivery of value, but you also need to consider the needs of the team. Those needs often represent themselves in areas like: infrastructural, architectural, and refactoring investments; as well as in tooling for automation, testing, and code maintenance.

It’s these investments that often drive speed to market and quality improvement results. But they also reap good will and morale on the part of the team, as they feel you’re investing in their “health” as well as the product and that you’re listening to them.

A Story

In many of my Product Ownership classes I offer a dilemma to inspire thinking around balanced backlogs. I mention a hypothetical team that has a small group of database engineers on it—one is the lead and two are interns. The lead is about to go off on maternity leave for 2 months and she typically took on all of the complex back-end work for the team. While the interns have some knowledge and skill, consider what was a 2.5x productivity proposition across the three of them to be a .5 proposition with her on leave. So in essence a very significant drop in overall backend capacity.

As the Product Owner, would you alter the flow of work based on the capacity and skill-set change? Even if the business (customer, your boss, Senior Leadership) was pushing you for more functionality with significant backend implications?

Or, would you drive the work through the team independent of their capabilities simply because that was the right priority flow?

Personally, I would change the flow—balancing it towards the new capability of the team and wait for the lead engineer to return. Yes, I would make this transparent across the organization. And certainly I would also welcome some more experienced replacements, if we had them.

But I would focus on balance in the backlog even in the face of mounting “value pressure”. I think an important part of the job is maintaining your balance under pressure and adversity.

What’s the Mix?

There are essentially two ways to handle the capacity allocation mix in Product Backlogs. Either your leave it to the discretion of each Product Owner to “load” their backlogs appropriately or you define a specific target mix.

I always prefer the former approach IF the Product Owners feel empowered to own their backlogs and invest in the future of their products. But in nearly all of my experience, that isn’t the case, with the vast majority succumbing to the business pressure and creating Feature3 backlogs.

In order to combat this lack of empowered balance, many organizations negotiate a fixed ratio for their backlogs. A common one I see is 80:20; that is 80 percent features and 20 percent investment in other areas—sometimes including bug fixes. In several companies where I was the VP of Development and their internal Agile Coach, we leveraged this mix for our all of our backlogs.

What was interesting is that sometimes, we struggled to fill in the 20%, which always boggled my mind. It seemed that the teams were reluctant to write the stories to describe the 20% work, even though they continuously complained about the business’ background investments in our products.

Salesforce.com

Salesforce has an interesting twist or at least had it in the 2009-2011 timeframe*. In their case, they established a 20% “penalty” for products that didn’t minimally have 70% automation coverage, which often occurred with new product acquisitions.

What did that imply?

That they would invest in a normal mix for their products, let’s say 80:20. But if a product lacked sufficient automation coverage, they would invest an additional 20% of the backlog to bring the automation up to speed with their norms. And what’s even more interesting is that this was driven top down by management and not by the teams.

I particularly like this story because it amplifies the agile maturity of the Salesforce leadership team. They clearly understood that an investment in automation infrastructure was a longer-term investment in their products.

SAFe Recommendations

Moving on to another example. The Scaled Agile Framework (SAFe) strongly recommends a balanced approach in handling team capacity as well. But unfortunately SAFe doesn’t make any strong recommendations as to effective ratio’s or balance propositions. They simply leave it up to the organization to make that decision on a PSI by PSI basis.

While I understand that position, there are other areas within SAFe where they are quite prescriptive. I wish this were one of them. Here’s the reference for capacity allocation in SAFe.

Wrapping Up

I hope this article has at least influenced your thinking around capacity management and balance within your Product Backlogs. If you’re a Product Owner reading it, then I want you to walk away knowing that this is a significant part of your job—a job that your teams are depending on you to do well.

My main point is that you avoid Feature3 Syndrome. The other point is that it will take dogged determination, a longer-term view, and courage for you to maintain a healthy balance—particularly under pressure. While that may be a great challenge, your team will respect you for it and your products will be more successful if you achieve that balance.

In the end, it’s your choice.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

*Salesforce mentioned this at several conference presentations in that timeframe. One noteworthy example was at the Agile 2010 conference. I believe Steve Greene was the co-presenter.

Grooming, Maintaining, or Refining your Backlogs – Practices for Success, Part 2

Written by Robert Galen on . Posted in Articles. 1 Comment on Grooming, Maintaining, or Refining your Backlogs – Practices for Success, Part 2

In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition. In both books I took on the topic of Backlog refinement.

In part one of this post, I set the stage for what backlog refinement was by referencing the Scrum Guide. Then we explored 5 of 12 overall refinement tips. I’ll continue with the remaining seven tips here:

12 Tips for Effective Backlog Refinement

6. Talk Less, Spike More – I’ve noticed a very common anti-pattern in many refinement sessions that teams explore each story far too deeply. They wax into conjecture and guessing about design challenges. They debate implementation approaches. They argue estimates on stories that are still quite immature and ill defined. In a word, they talk too much about the stories.

I’d much rather they define a spike, do some research, write some code, talk to a customer, and do whatever it takes to replace “talking” with “real learning and knowledge”. And I don’t think this happens in a roomful of people. It happens individually and more effectively in pairs looking at real prototypes and code.

I have a personal heuristic that up to 20% of the stories in a typical Product Backlog deserve to be spiked. What I more commonly see from most teams is 1-2% of their stories getting spiked. I think most software projects have more complexity than that, which is exactly what a user story – research spike is intended to mitigate.

7. Remember, Refinement is Planning Too! – Backlog refinement goes far beyond requirements definition. It’s also part design, part planning, part strategy, and part risk mitigation within your sprints. This is one of the reasons I prefer that teams sample their stories multiple times and leave a little time between refinement sessions. It allows for “think time” across the team, which leads to better stories, better execution, and more consistent delivery of value.

Another important point is to look beyond the individual stories when you’re refining your backlogs. Instead, ask your Product Owner about features and themes (collections) of stories that they want delivered together or that are related. Here you should be looking at dependencies and risks. But also look for efficiency in implementation. For example, coupling a set of four stories together in priority so that you can do some related refactoring and improve the service API that all four will leverage.

8. Reserve 10% of the Teams Time – Too many teams make the mistake of reserving too little time for backlog refinement. I remember early on in my Scrum journey hearing Ken Schwaber talk about “reserving” 10% of the teams’ time for refinement. You see mention of that in the latest Scrum Guide (above) as well.

That would be 4 hours, per team member, per week. He made the point that it’s that important and the team needs the time to do it well. Fast-forward to today, and most teams might allocate a 1-hour meeting per week to refinement and cancel that if the sprint is running into challenges. Teams need to make a serious commitment to their refinement activity. And remember, it’s not just in meetings. I believe each team member should take some personal time each week to work on improving the backlog. That might be improving the acceptance criteria in a story, or asking targeted questions, or suggesting a story be spiked, by who and for how long, or writing a technical story to clean up some technical debt.

The point is refinement should be a continuous activity by all team members and not something relegated mostly to meetings or to the Product Owner.

9. Never Cancel Refinement, in fact, Do More! – As I alluded to in the last suggestion, it often seems like teams find excuses to defer or cancel backlog refinement whenever possible. But what I’ve found is that this is the last thing you should do if you’re challenged in your sprints. Refinement goes way beyond requirements definition. It’s also part design, part work planning and tasking, part strategy, and part risk mitigation within your sprints. Point being, if you’re struggling, don’t stop planning your work. It will only lead to deeper struggles and missed commitments.

Let me add another heuristic here. If you find your sprint planning meetings going on and on, then you’ve probably been under refining. Conversely, if you are performing sufficient backlog refinement within your team, your sprint planning meetings should be effective, focused, and quite short.

10. Develop & Apply Readiness Criteria – From my perspective, there are very few things worse for an agile team to do than to take an under-cooked story (under refined) into a sprint. Inevitably that story “blows up” into more than the team expected in size, scope, complexity, dependencies, or something else and it causes the sprint to fail.

Beyond the disappointment to the Product Owner and business impact, it causes the team to lose confidence and feel bad. Not only that, the work typically falls to the next sprint to complete, so there is a cascading effect.

I wrote about a method for avoiding this called Readiness Criteria here . I’d strongly recommend you apply this technique. Consider it story exit criteria from your backlog refinement sessions.

11. 3 Levels of Lens OR Change Your Focus – With a new team or project, your backlog refinement clearly needs to focus on the work that you will be tackling in the immediate future (next sprint). But as you continue to sprint and continue to refine, you should be getting ahead in your backlog. When this happens, I like to change the focus a bit in the refinement meetings. I have a 3-lens metaphor for this, in that you should be refining:

  • Stories that are “right around the corner” – 1-2 sprints in the future
  • Epics, Features, or Stories that are targeted for the next release target
  • Epics, Features, or Themes that are targeted for future releases

To keep the refinement meetings interesting, we’ll examine stories through these various lenses—sometimes shifting the view in the same refinement meeting. One advantage is it forces the Product Owner and team to “connect the dots” between the now and the future, both from a functional and architectural perspective. It also motivates the team because they get glimpses of their future work.

12. Anchor Your Sprints with Themes – One of the problems with backlog refinement is that it usually deals with finely grained units of work—call them stories. The refinement then focuses solely on each story. While this is certainly important, I’ve found two problems with many teams handling of this:

  • The focus too much on the story and little to no time on the “collections” of stories, the themes, and the workflow from sprint to sprint
  • They break the stories down too far, further than they really need to. Sometimes they even break them into tasks, which should be deferred to sprint planning.

In this related article , I refer to the notion of creating an anchor story for each sprint. This story would be large and complex, but it would be sized to fit the sprint—in other words, it would be an “executable” story. This story would more heavily influence the sprints theme or goal and other stories would build around and support it.

If you take this anchored view to your backlog, then finding these stories and building content around them would be an aspect of your refinement thinking.

Wrapping Up

There are five-core scrum activities defined in the Agile Atlas as central to your execution of Scrum.

  1. Sprint Planning
  2. Daily Scrum
  3. Sprint Demo
  4. Sprint Retrospective
  5. Backlog Refinement

All of them are important and have specific values they add to your agile execution and results as a team. I think of Backlog Refinement as being the “planning” focused ceremony. Not just planning for the sprint, but planning across a multitude of factors that a team needs to keep their “eyes on” to successfully deploy customer solutions. A huge part of it relates to what I call look-ahead.

I hope this article has helped to widen your thinking about Backlog Refinement—the what and the how of it. But at the end of the day, these are simply my thoughts and experiences. Bring yours to bear in your contexts and see what approaches will work for you.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.