Top Ten -> Twelve JQL Tips to Improve Your JIRA Searches

Jira ate my brain

JQL – it’s not just for programmers.

Somehow I keep ending up at companies that use Jira and Jira Agile for tracking their teams’ work,  I’ve been using Jira and Confluence a long time – Confluence since it came out in 2004  and didn’t have a rich text editor – and so no matter what my official role, I end up doing a lot of troubleshooting and help for folks using these tools.

So today I thought I’d share some tips about querying with Jira.  If you use Jira, you know that it supports a basic dropdown and picker-driven query UI like this:

Jira basic search

This is great as a starting point, but to really get to the good stuff you’ll want to click Advanced and start typing Jira Query Language (JQL) instead.  It’s modeled on SQL (Structured Query Language) for databases, but don’t be intimidated – JQL doesn’t go much beyond the equivalent of SELECTing things WHERE certain criteria apply.  For example:

Go ahead, give it a try!  Advanced mode has auto-suggest, so just start typing a field name and see what happens.

Background Reading

The tips below are some good secret sauce drawn from common questions I get, but if you want a more general introduction, head over to these places:

Ok, on to the tips.

Top Ten Twelve JQL Tips

1. Learn JQL by Switching Between Basic and Advanced Mode

Learn by doing! Use Basic mode to build a query then click Advanced to see the JQL JIRA created to run your query. By working back and forth between the two modes you can figure out quite a bit. You’ll know you’re getting good when you write JQL, click Basic, and get the message “this query is too complex to display in Basic mode”.

2. You Can Query The Past

JIRA supports query operators like WAS for some fields. For example you can write stuff like:

to find all the issues John Price started progress on before 2018. Cool!

3. Saved JQL Queries Power Dashboards

Dashboards are a whole other topic, but making dashboards for yourself or others basically consists of:

  • Writing a JQL query and saving it.
  • Creating a dashboard.
  • Adding charts and other gadgets and telling them to use your saved query as the data source.

Don’t forget to have someone test your dashboard to be sure you’ve properly shared it and its queries.

4. Email Me Those Query Results!

This isn’t strictly a JQL tip, but you should be aware that you can Subscribe to any saved filter and have JIRA email you a list of matching issues weekly, daily, or more often. This is a great way to be reminded to go check JIRA for things like:

  • all the new stories created on the backlog in the last day (these need to be prioritized)
  • all the support requests that no one has picked up yet
  • issues missing important data (no Component, Product, etc.).

You can also use subscriptions in conjunction with a less chatty Notification Scheme (ask an admin) to cut down on the dreaded Jira spam.

Check out Receiving Search Results Via Email in the official JIRA documentation.

5. Query For Empty Resolution To Find All Open Statuses

If you want to find issues in any open status (New, In Progress, In Test, etc.) it’s a pain to list all the statuses in your query. When an issue gets Closed or set to a done-equivalent status like Awaiting Deployment, a second status-related field called Resolution gets set to Done by default, or to other values like Won’t Fix if your workflow lets you manually choose it. Also, Resolution gets cleared automatically when you reopen an issue. That means that:


is shorthand for something like

and way easier to type.

6. Search All Text Fields At Once

For free text fields you use the tilde (~) instead of equals (=) to match content. It basically means “contains”, like this:

But sometimes you aren’t sure if the text you want is in Summary, Description, Acceptance Criteria, or somewhere else. So you can just type:

and JIRA will return matches for all those fields plus any other text fields.

7. Search Projects By Key, Not Name

If you want to limit a search to a project, either the name or the key will work. The project key is the alphabetic part of the issue IDs in that project, like CATS for CATS-123. So you could save queries like this:

But if the team changes the project name to “The Cool Cats” all your saved queries will stop working. JIRA auto-suggests the names, which doesn’t help you have good habits in this case. Instead you should always use:

so the queries keep working if the name changes. As a bonus, this keeps working even if the key changes since JIRA keeps track of old project keys. The Tooth and Paw team became Cool Cats a while ago, but you can still type

and it will give you a list of Cool Cats issues. Like magic.

8. Functions Are Your Friend

Most simple queries look like this:

This one gives all the bugs I’m working on right now and is just a list of “this field has this value and that field has that value” statements. But JIRA has lots of built-in functions to simplify your life and you can drop these right into your queries in a straightforward way, like this:

This shows me all the open items assigned to me that are in past sprints. There shouldn’t be any … but I like to check now and then to keep JIRA neat. Better yet, because I said currentUser() instead of “john.price” I could save this as “My Old Open Issues” and share it, and each person running it would see their own list of old open issues. Maybe I’ll even get my team to Subscribe to the filter (tip #4) and they’ll get an email every Monday to remind them to clean up old issues.

9. Parentheses Matter

Just like in SQL, you can use parentheses to tell JIRA how to interpret what you want. Let’s say I want all the CATS project issues assigned to either me or Felix Cat. I can write

but JIRA thinks I mean “CATS items assigned to Felix, or any item assigned to me”. I can tell something’s wrong because if I swap the order of names I get a different number of results. So I use parentheses:

which JIRA reads as “in the CATS project and assigned to one of these two people”. By the way, in this particular case I could have just done this:

but I wanted to show how parentheses work.

10. Know Your Dates

Writing useful JIRA queries often means restricting results to a date range. How many bugs were found during Program Increment 2? How many open issues haven’t been updated in over a year? Where are those issues I created today?

There are three ways to specify dates in queries:

Use the actual date, like:

This returns everything created after the start of 2017.

Specify a time relative to today, like:

This gives you everything created within the last 7 days. The results change as you run the query over time.

Use some of the built-in date functions, like this:

This works just like the first example but will stay useful if we run it next year. You can also give a number to the various startOf/endOf functions if you care about a day, week, month or year other than the current one, like:

This will always give you issues created during the previous full calendar week (Sunday through Saturday).

11. EMPTY And Not Equal Are Not The Same

You can write IS EMPTY in your queries to ask for issues where the field in question has no value specified. But if you’re not a developer or SQL expert you might be surprised by how this relates to the not equal ( != ) operator. Not Equal means “has a value, but not this one” and doesn’t return issues that have no value at all. Let’s say I want to find bugs in my project that have the wrong product specified. My product is Cat Toy Caddy so I type:

That’s great, but as it turns out there aren’t any with a different product. But there are a bunch where we forgot to put anything at all. Let’s try again:

Ahh … there we go. Note the parentheses.

12. Supercharge Your Text Searches

You may have noticed that JIRA doesn’t always seem to find issues that contain the text you’re searching for. Like:

doesn’t find an issue called “Integrate RealtimeBoard With Confluence”. What gives?

JIRA uses Lucene (a popular search engine) for text searches. Lucene uses something called word stemming instead of doing exact text matching. So searching for “customize” will find “customizing” because they are forms of the same stem, but searching for “cust” finds neither. Luckily you can just do this:

and now it finds your issue. All we did was 1) add an asterisk to the end of the word to tell JIRA to find anything starting with “conf” and 2) put the text in quotes so the asterisk doesn’t create a query syntax error.

For more advanced text searching tips, see

Just a couple more examples for fun:

Note how in all cases the whole text search including operators like AND and NOT is in quotes.

Whew, That Was a Lot

Hopefully even those of you who have been using JQL for a while found something new.  You should also take a look at some of the popular JQL-related plugins like the JQL Tricks Plugin (Server only) or JQL Search Extensions for Jira (Cloud or Server), which give you even more search options.  

This is just the beginning … have fun!

Don’t Give Up! A Story About Impediments


snail crawling on pavement

This snail thinks it’s speeding along. Do you?

Let’s talk about impediments.  “A hindrance or obstruction in doing something”.  From the Latin impedire, to shackle the feet of.  A thing that slows you down or keeps you from moving forward.  Simple as that.

And yet every day I go to stand-ups or Scrum of Scrums meetings and I hear people go around the room: “No impediments.”  “No blockers.”  Really?  There’s nothing standing between you and your ideal flow state where you code, test, or write stories all day in your dream office on your dream machine with no interruptions and churn out only the best bug-free features with no tech debt and no escalated support calls?  Are you guys hiring?  I wanna come work there!

Often when people say they have no impediments they mean that they have no unusual impediments.  Or they mean that they have none that they think anyone can do anything about. Other things that keep people from reporting impediments:

  • They’re embarrassing:  “We’re about to do some Angular and I don’t know anything about it.”
  • They involve interpersonal dynamics:  “There’s a person on the team who won’t explain their code to me.”
  • They involve money.  “This laptop is too slow.”

I have a true story about that last one.  Read it and let me know if that changes your mind about handling impediments.

So … slow.

When I train Scrum Masters I always stress their role as impediment removers.  Some take naturally to this part of the job, while others need some assertiveness training.  I myself tend to naturally avoid conflict so I often have to remind myself to practice what I preach and not shy away from the hard problems.

Anyway, there once was a newly minted Scrum Master who was very gung-ho about the role and almost immediately let me know that his team’s top impediment was that their laptops were too slow. I agreed and pushed a request for faster laptops up the chain.  And … not in the budget.  Also, I was told, the machines aren’t too slow: the teams have designed an app that’s too complex and thus puts a strain on the machines when running locally.  Which was true to an extent, but not that helpful in the short term.  I tried to push it a bit but got a very firm answer again: this isn’t going to happen.  Make do.

laptop with stethoscope and crumpled paper

Is it doing anything? I can’t tell.

Reader, I’m embarrassed to say that I gave up at that point because, well, that’s just how things are around here.  But my Scrum Master trainee didn’t.  He started to collect data from the teams:  mean time to open the application in the IDE, mean time to start debug mode, mean time to run all the unit tests, and so on.  He made videos.  He showed them to people. Eventually he found the company’s employee suggestions site and wrote a long and compelling case for better laptops, which included calculations of the cost of lost productivity versus the extra cost of a fast machine.  He then started networking with developers on other product lines and in other offices and got them to all go vote for his suggestion, which then became the #1 hot item on the suggestions site.

This got him an audience in front of the executive team, which was delayed but eventually happened.  Between this and some cajoling of a new development director, the first new and souped-up machine finally arrived.  Benchmarks showed it did indeed cut task times by a huge amount and as machines aged out they were replaced with the new spec, which made its way to the IT department as the updated company “performance laptop” standard.

This entire process took close to a year if I remember correctly.  The Scrum Master did not get a fat bonus or much official recognition for this, but I’m going to go out on a limb now and say that was one of the all-time legendary impediment removals.  No mandate, no seniority in the company, just good old-fashioned stick-to-it-iveness.

Are You Fighting That Hard For Your Teams?

As a Scrum Master. impediment removal is one of the single best uses of your time once a team is up and running with the basics of Scrum.  You are directly targeting waste and by doing so increasing your team’s velocity and most likely its morale.  Also, if you’re not a technical member of the team, you’re gaining the team’s appreciation and respect and helping the organization see the value of the Scrum Master role (Hey, it’s OK to have a selfish motive thrown in there).

Don’t get me wrong – it’s not always easy to solve impediments.  Many times even getting the team to recognize and raise them takes quite a bit of creativity and effort.  But don’t let that stop you.  You’re a Scrum Master – Master of Scrum!  So use your Courage and Commitment – two of the five Scrum values – and dig into those impediments.  What are you waiting for?

When Agile Isn’t

agile word tiles

How much can we take away before it’s not what it was?

OK, philosophy time: When does a thing change so much that it ceases to be that thing?

Let’s Play Football, or Something Kind of Like It

Let’s take American football.  If I tell you I’m playing football, but that we aren’t wearing helmets or uniforms, is it still football?  What if we are using tear-off flags on our waists instead of tackling each other?  Still OK?  What if we have 5 players per side instead of 11?  What if we don’t allow forward passes (they once weren’t allowed, actually)?  What if we use a round football?  What if we don’t keep score?  You get the idea.  There’s some fuzzy point where the Reasonable Person of jurisprudence would agree “That’s … not football.”

For a more entertaining example of the difficulty of precise definitions you can check out the Sandwich Alignment Chart.  Is a burrito a sandwich?  I’ll warn you: it’s a pretty deep rabbit hole.

It Says “Agile” On The Carton But It Smells Kind of Weird

pouring milk

Can I drink this? Seems dubious.

Those of us who have been coaching Scrum, SAFe, Kanban or other “agile umbrella” practices for a long time tend to have a pretty good sense of when the basic tenets are being violated.  It’s tough to call out, though, because we also tend to want to avoid prescriptivism; if a team finds some change to a process works for them, great!  They are self-organizing, right?  Yes, but1 it’s OK to probe a bit into the intentionality behind the way teams are working.  Are they fully aware of the Agile Manifesto principles?  Are they professing to do a specific agile flavor such as Scrum?  How did they arrive at where they are?

1(pretend I said “yes, and” if it makes you feel better)

There are plenty of ways to go about assessing a team’s agile adoption.  For example:

  • You could administer one of the many team health surveys, such as the Spotify squad health check, or roll your own.
  • You could do an agile maturity assessment.  Ben Linders has a nice article on this and provides a mother lode of assessment links.
  • You could retrospect with the team and discuss the various aspects of Scrum (for example) and how much they feel each ceremony, role, and artifact is adding value.  You might be surprised at what you hear.

The important thing is that you as a coach or other leader are hyper-aware of how things are going so you can present and facilitate the right learning paths for the team.

What Exactly Is This We’re Doing?

“We’re Agile”

The more specific you get with with what you’re professing to do, the more you’re on the hook for the details.  This is probably why many people stop at “we’re agile” which in the modern world is like saying “yes, we develop software”.  So I guess those folks just need to live up to the Agile Manifesto and its 12 associated principles.  As long as the team talks to business stakeholders every day, works reasonable hours, has regular retrospectives, has regular face-to-face conversations, delivers software no less frequently than every couple of months, and … yikes does it really say all that?  Yep.

“We Do Scrum”

Scrum teams try to live up to the Agile Manifesto while also adopting more specific roles, ceremonies and artifacts: Scrum Master, Product Owner, daily standups, sprint planning and review, retrospectives,  and prioritized product and sprint backlogs.  They also follow the Scrum Values: commitment, courage, focus, openness, and respect.

I’ve been accused of being a prescriptivist when it comes to Scrum, but that’s because I’ve been able to help a lot of teams by getting them back to basics and investigating why they felt the need to skip retrospectives, not make the backlog visible to the teams, or whatever else.  It’s been pretty rare in my experience that teams have invented a brilliant new version of Scrum and pretty common that they’ve been cutting corners or just are not willing or able to commit to the mindset required.

“We Do 4-level SAFe 4.0”

If you know SAFe, you know it adds a slew of details on top of plain ol’ Scrum or Kanban.  It does a good job of explaining how to scale agile to many teams and defines processes that handle economics, coordination, shared resources, and medium and long-term planning.  However, if you’re going to say you do SAFe you should have Release Train Engineers, ART Sync meetings, Weighted Shortest Job First story ranking, and all that good stuff. You also get the 9 SAFe Principles on top of the Scrum Values and Agile Principles you’re already following.  You are decentralizing decision-making, right (#9)?

Labels Schmabels?

Only you can decide how you want to label your Agile implementation or whether you even want to at all.  Personally, I try to take care to be specific, like “We have a pretty strong agile program.  Most of the teams do Scrum but we have some Kanban support teams.  We’re still releasing on a long cadence though because our CI/CD and test automation practices just aren’t there yet.”

If I name a specific framework like SAFe, you should expect that I have a thorough working knowledge of the theory and can reel off the ways we aren’t in alignment with it, and for each I have some plan to get there or else a defensible argument as to why we aren’t going to implement it.  I think that’s only fair to the creators of those frameworks.  If I make no pretenses about named processes (“we’re rolling our own”) then it comes down to whether we’re following the agile principles.

It’s the Thought That Counts

I don’t think it’s helpful to go around pointing out all the ways teams are doing agile “wrong”. The reality is that it’s possible to succeed with or without normalized story points, or with two- or three-week sprints, or with all sorts of other minor modifications and variations.  However, in the spirit of reflection – “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” – I encourage you to be honest and open with yourselves and your teams about the current state of your agile journey.  Is it a work in progress?  Say that.  Does it feel like your agile implementation is in trouble?  Be forthright about that and get feedback from the teams and your leadership team.  And start with the values …

By far the most important goal for any agile team or organization is to work to embrace the chosen values and principles, whether it’s just the Agile Manifesto or the Scrum values or SAFe Principles.  Adoption of specific practices follows much more easily after that because (hopefully) they tie directly to the values and you can thus justify them in that light.  You can also self-evaluate your practices against the values.

In Closing: Is It Agile Or Not?

I have a hard time compromising on the Agile Manifesto and the twelve related values.  If there’s not at least an effort to live by those, it’s not Agile to me.  But certainly many companies happily implement Scrum, SAFe, or some other framework and just completely gloss over the underlying ideas.  That makes for a sort of Hollow Agile that often fails to deliver the expected results and leaves everyone feeling burned.

Don’t worry, there’s no Agile Police, so you can keep on keepin’ on without fear.  No one’s going to take your license away because you skipped a retro.  But I hope this post has helped you think about what it means to be agile and to frame what you’re doing more clearly to yourself and your teams.  Now get back out there and deliver some customer value!

bored lemur

Courage, Conferences, and Coffee

Today I have for you a hopefully inspirational little anecdote about recognizing wastefulness (muda in Lean terminology) and having the courage and initiative to eliminate it when you see it.  In this particular case, the wastefulness involved waiting for something very important to me personally: coffee.

Conference Coffee For Five Hundred

I’m not sure exactly how many people turned up recently at the wonderful TriAgile 2017 conference in Raleigh, NC, but I can tell you that a lot of them wanted coffee at about the same time.  In between sessions I wandered into the dining area and got in line for the self-service coffee station, which was set up against a wall on a folding banquet table, like this from left to right:

3 big coffee urns / 2 smaller hot water urns (for tea) / coffee cups / coffee accessories / water cups / water urn

I forgot to take a “before” picture, but the key takeaway is that the process went like this:

  1.  Person A (let’s call him Alf) goes to the middle to get a coffee cup.
  2. Alf steps to the left a bit to dispense coffee, but is still sort of blocking the cups.
  3. Person B (let’s call her Beth) waits patiently a few steps away.  She needs a cup for tea.
  4. Alf steps to the right a bit to begin his fiddly process of making his coffee Just Right:  Grab one sugar.  Grab a Splenda.  Tear and dump into cup.  Toss empty packets in tabletop trash bin. Grab two creamers.  Struggle with opening creamers due to obsessively short fingernails (probably a programmer).  Pour creamers.  Put creamers in bin.  Get stirrer. Stir.  Put stirrer in bin. Take a sip before moving because it’s too full now.  But carefully – it’s hot!
  5. Beth experiences the fourth type of waste (Waiting) from an uncomfortably close perspective.  The next session is about to start.
  6. Finally Alf steps away, which allows Beth to get her cup and tea bag, add hot water, and head off to her next conference session.  Luckily for person C (Calvin), Beth drinks her tea plain.

Are you getting annoyed just thinking about this?  I was in a pretty good mood as I watched this happen a few times in front of me, but as I got to the front I couldn’t resist saying to the next person, “Excessive queue lengths … if we were really agile, we’d fix this ourselves.”  I got the sort of laugh I usually get at my bad jokes and he wandered off.  But then I decided to step back about 10 feet and watch the coffee line for a few minutes.  Without fail, each person with non-trivial coffee requirements would block the entire table for a minute or so as the next person quietly and politely waited.  I kept an eye on my phone timer to get an idea of the amount of delay.

None of these people seemed to notice how long this was all taking.  Obviously, this situation called for a hero of sorts.

He’s a Man of Action!

As soon as there was a break in the line, I looked around for a banquet staff member but none were to be found.  But there was a second, tantalizingly empty table just to the right. So I did this:

Optimized coffee station

Ahh … much better.

As you can see, I moved all of the coffee condiments (sweeteners, creamer, and stirrers) out from between the coffee cups and water cups and over to the next table.  What do you suppose happened next?

The next person came up, poured a cup of coffee, glanced around, and happily wandered over to the new table to mix all the extras in.  And the next … and the next.  There was even enough room at table #2 for multiple people to work side by side.  No one questioned the new setup or had seen me make the change, but they moved through the system noticeably faster.  As a bonus, people who needed something simple like water or plain tea or coffee had virtually no wait time.  Hooray!

Be Bold

The surface lesson here is that there’s waste in almost every system and that improvements can often require surprisingly little effort.  But there are more important things to see.  In order to make the process improvement, I had to feel empowered to do so.  I didn’t worry too much about whether the staff would get mad at me; after all I had a good reason for doing what I did. Still, it took a small amount of courage I suppose, and courage is one of the five core Scrum values.  I hope that when you come to work with your agile teams each day, you trust your instincts and feel equally bold about making your team and process better.

Step Outside Yourself

Ok, so I took a small risk and Just Did It.  And yet before I even made the decision I had to notice that something was wrong.  I’d wager that most of the people waiting just accepted a slow line as their destiny for that moment.  We’re all used to waiting in lines, right?  In my case, the idle time spent in line is actually what allowed my mind to wander outside the system I was in and realize how silly it was to just take the current parameters as given.

Now think about your agile teams and whether they are truly taking matters into their own hands when it comes to the various inefficiencies they deal with as they try to complete all the sprint work they’ve undertaken.  In many cases I’ll bet they are surfacing and solving small problems in their retrospectives while the true “elephant” problems persist.  Are they convinced they aren’t allowed to tackle the big ones?  Are they so busy that they don’t even notice?  If they’re always working at or above capacity it may be the latter.

As a coach or leader, encourage brainstorming, outcome visualization and other techniques that put people into the state of mind that’s needed to generate those a-ha moments that really move teams to greater efficiency.

Perfect for a While

After all that, I’m sorry to have to tell you that eventually afternoon snacks arrived and needed to go on the second table, so the event staff moved the coffee stuff back to where it was.  I think it survived at least an hour though.  And of course this is a solved problem in general – go into any decent coffee shop and they’ll have the coffee urns together on one counter and there’s a totally separate counter for putting other stuff into the coffee.  It’s obvious when you pay attention – systems thinking, right?

Thanks for reading – see you next time!


Lies, Damned Lies, and Agile Metrics

rusty metric measuring tapeWhy do we measure things, or in this case, agile teams?  Well, we might want to know what is likely to happen in the future (prediction), or we might want to know if we’re getting any better (progress), or we might want to see how much value we’re getting out of one team versus another (productivity).  In order to make sound business decisions, we’ve got to know about all these things.  But too often we forget that measurements of human teams building new software are not exact.   Not only that, they sometimes conflict with the qualitative results we see in reality.  As an agile leader, it’s important to counterbalance graphs and and calculations with quite a bit of Management By Walking Around, a healthy dose of Gut Feel, and a heaping portion of Actually Using The Software Yourself.

Please realize that I’m not arguing against metrics.  They’re a crucial part of any agile endeavor and the lean enterprise.  But let me tell you a story about measuring teams.

Which Teams Are Giving The Most Value?

There once was a product that had teams working in two locations.  Several of those were in the United States, where tech salaries tend to be quite high.  Other were in a different country – let’s call it Freedonia as a Marx Brothers tribute – where the team cost was significantly less (60-80% of the US team).  Both teams estimated stories using Fibonacci series points (1, 2, 3, 5, 8, 13 …) and management tracked the teams’ velocity over time.

After about a year of this, management looked at the velocity charts and it was very apparently that the Freedonia teams were consistently delivering more story points per sprint.  When they factored in the lower cost of the Freedonia teams, the difference was even more stark.  Conclusion?  Invest in expanding the Freedonia teams!

Hm, you think.  He wouldn’t be telling this story if that was the end of it.  And you’re right.  Here are just a few of the problems with the conclusion that was drawn.

Problem 1 – Lack of Normalization – This one’s the easiest to spot and fix.  The teams in the two countries were not estimating relative to the same baseline.  Instead, The Freedonia teams tended to assign much larger point values for comparable stories.  So the US teams would consistently estimate and complete 35 points while the Freedonia teams sometimes did up to 80!

Problem 2 – Externalities – If you’ve studied economics, you know that externalities are (roughly) costs or benefits that don’t get quantified as part of an economic transaction.  In this case there were some major unbalancing issues in play.  Most notably, the US teams and their associated business colleagues spent a very large amount of time attending to the technical and requirements needs of the Freedonia teams, because of their overall lower level of familiarity with the product.  That is, the Freedonia teams were creating some drag on the US teams (through no fault of their own).  Also, due to time zone, language, and product owner location issues, the cost to transfer information to the Freedonia teams was much higher.

Problem 3 – Customer Value – Remember, story points or SAFe’s 1-10 scale business value don’t equal customer value.  Customer value equals customer value.  At some point, someone decided to step way back and look at a list of the features delivered by each set of teams over a period of about 12 months.  It looked something like this:

US TeamsFreedonia Teams
Internationalization of product
Metrics dashboard and widgets
Task management
Custom fields
HTML5 screen template builder
Complex international accounting
Third party accounting software sync
Roles and permissions system
Product tiering
Accounting sync enhancements
Bulk document upload
Task management (later redone by US teams)
Page-specific permissions
Spike - doc management (not implemented)
Spike - additional accounting sync

Without knowing too much about the specific product, it’s pretty obvious that the US teams delivered many more meaty, releasable features, while the Freedonia teams took more of an assisting role extending existing features. There were also several spikes that ended up as lost sunk costs since they didn’t end up as released features, and most notably a feature that had a large number of design flaws and bugs which had to be rewritten by a US team.

This doesn’t imply that the US teams were “better”; but they did have more domain knowledge and the advantage of being collocated with the Product Management, architecture, and UX teams. At the very least, deciding to expand in one location over the other should have taken into account the qualitative track record and the other situational advantages of the US teams.

Change Is Gonna Do a Number on Your Metrics

hand adjusting sound mixer fader

Change is constantly happening and affects the viability of your metrics.

My background is in science, where experiments are tightly controlled and the goal is, when possible, to change one variable at a time in order to determine its effects on a system. It’s important to realize that although we talk about agile experiments, they are not and will never be scientific experiments. You’re not building the same feature multiple times (I hope), and products, teams, and environments change so frequently that most metrics need to be taken with a shaker of salt.

Off the top of my head, here are a few things that can affect team velocity (and delivered business value), which is one of the most important metrics in agile teams:

    • someone new joined the team
    • someone left the team
    • the Definition of Done was made more stringent
    • production issues or other operational distractions
    • new Product Owner or ScrumMaster
    • vacation or illness of key personnel
    • larger organizational changes
    • moving offices
    • variable sprint length (yes, people do this)
    • quality of stories and requirements for a specific feature
    • new technologies being introduced

I’m sure there are others, but you get the point. You really aren’t ever comparing apples to apples when you’re measuring your teams.

Baby, Bathwater, Etc.

Having said all this, I love me some metrics. I love pretty graphs and charts, especially when I can draw a trend line through them that shows teams getting faster and better. But I try to be aware of their limitations in describing what’s really happening in my teams and why. Most importantly, I balance them with cultivating a deep knowledge of my teams and products as they exist in the real, non-mathematical world. I talk to the developers and testers. I play with the software and read users’ anecdotal feedback.

I’ll leave you with a short checklist you can use to evaluate your metrics and be appropriately careful about the conclusions you draw from them:

    1. Certainty – What is the level of certainty of this metric, and do all parties understand the error margin? Or are some parties taking SWAGs (Sophisticated Wild-Ass Guesses) as hard truth?
    2. Hackability – How likely is it that people are deliberately or subconsciously gaming the metric to please management?
    3. Variability – What changes to the teams or system are occurring over time that might affect the metric?
    4. Predictiveness – If you step back and look at the team or system in a qualitative, not quantitative, way, does the metric square with what you’re seeing on the ground?

Please think about this and balance metrics with other observations, and do your best to ensure that more perspectives than just raw statistics make their way up and down the leadership chain.  Good luck and happy measuring!

The Product Backlog: A Journey In The Mist

Man walking in the mistI’ve been working on reviewing an upcoming agile book and there’s a nice discussion in it about the various metaphors that people use to describe product backlogs in Scrum.  They all get the point across, but I thought I’d try to come up with an alternate visualization.  And then I had a dream about it (really)!

Something’s Bugging Me About Icebergs

One of the most common backlog metaphors is the iceberg , where a small percentage of the backlog is very well defined and visible at the top (this math says it’s about 13% for actual icebergs) and the rest is progressively more coarse-grained and murky as you go down, until at the bottom you’ve got Big Ideas For The Future that aren’t clear at all.  The idea is that this is a good thing, because Lean principles tell us not to spend too much time worrying about low priority features we may never build.  However …

Let’s play a quick word association game.  ICEBERG!!

icebergI bet you thought “Titanic”.  So did I.  It turns out that the 87% of the iceberg that’s below the water is a big problem if you’re trying to navigate.  In the case of an iceberg, it’s actually *not* ok that we don’t know much about what’s down there, whereas with software development we’ve got to accept that and deal with it.  Also we can’t see the underwater part at all without special sensing equipment – versus the sprint/current release/future release gradation of a backlog – so the analogy kind of breaks down.

Stories In The Mist

So, here’s my metaphor for the backlog:  You’re walking through a misty landscape where the fog obscures your view beyond a few dozen yards.  You need to get to your destination – a small rural town which you know lies to the north – but you can’t see it.  You do have a compass to point the way, though.  You know you’ll have to cross rivers, rocky areas, and other obstacles but again, most of them are hidden from view.  Luckily, the colors and details of closer features stand out crisply against the white background.  You see some rocks and roots in the path and an incline to climb, so you note them as the most important and move forward.

As you reach the top of the small slope, more features emerge from the mist, and now you can see some vague larger shapes in the distance, including what looks like a foot bridge over a river.  You pick that as your goal and as you keep going, more trees and rocks reveal themselves with enough fidelity that you can navigate past them.

You doggedly hike on in the right general direction, picking short and medium distance goals and stopping every now and then to rest and check your compass.  Eventually you begin to see lights piercing through the mist in the distance and this gives you energy to quicken your pace, knowing that you’re almost there.  You hear the sounds of the town emerge: car tires on pavement, a dog barking, and you step out of the fog and the woods onto the main road leading into the town proper.  You’re just a mile away from a comfortable bed and a satisfying meal.  You did it!

What I Like About This

I like this metaphor because it emphasizes that while it’s important to have long-term goals (heading north to the town), most of the effort is in assessing the immediate and imminent surroundings to make good tactical decisions:  step over these roots, head for that bridge, etc.  It also adds a sense of movement.  You’re constantly traveling forward as you achieve small milestones, and that movement itself is what reveals and clarifies the next steps.  Even if you have some prior knowledge of the landscape, there are going to be surprises and that’s ok.  A bridge is out; a path is washed out by a storm or blocked by a tree.  There are no guarantees that the set of actions you end up taking to meet the goal are the same ones you expected to take.

What do you think?  Is this a useful way to think about the backlog?  Leave me a comment and let me know!

stones on foggy river


What If Your Scrum Team Was Funding You?

(This one’s addressed at Product Owners or anyone who is from the “business side” of a company. Not the “business end”; that’s something else.)

money growing in soil

Convince your team like you’d convince an investor and you’re onto something.

Teams Will Build What You Ask … Useful or Not

When I think of what I love about Agile and Scrum, I think: self-organizing teams, empowerment, creativity, customer collaboration (over contract negotiation!), no titles for development team members, exploration, experimentation, ownership … all things that assert or strongly imply that the development team is the beating heart of the whole enterprise, and that the rest of us exist to support them and enable them to build great things to delight existing customers and attract new ones. But the team is busy building things, and there are business-minded folks who spend more of their day thinking about what to build next and why, so even with the best of intentions many companies start to slip into a pattern like this:

The execs set the goals … then the sales, marketing and product teams meet a lot and decide what to build at a high level … then the product owner and business analysts meet a lot and decide what to build at a detailed level and in what order … then we tell the development team what to do.

But we know we should empower the teams, so we give them some business context during planning or grooming, or occasionally do “innovation time” or let developers tag along to user feedback sessions.

Which is great. But.

If you give the team useless features to build, they are going to build them just like they’d build amazing useful fantastic great features if you’d thought of those instead. They are going to negotiate scope during sprint planning and then Commit and gosh darn it, they will burn those 35 story points of useless crap down to Zero with Zero Defects and every Acceptance Criterion will be checked off. They might not enjoy it, but you’re paying them a lot of money and they all went through grueling technical education and they are predisposed to write code and write it well. But guess what? They probably have ideas about what you should build, and questions that go beyond story grooming, but unless you have a phenomenally open work culture and great communication (good for you!) then those ideas may not be getting enough sunlight and so you’re missing out, and so are your customers.

Let’s Pretend

So let’s pretend for a moment that the development team has all the money. One developer won the lottery, another comes from old money, and the QA lead has reaped the benefits of 3 straight IPOs. But for some reason they all keep working and they’re funding your company. I know, it makes no sense … suspend that disbelief like when you watch those superhero franchise movies.

Everything else is the same as the real world. The Product Owner ranks the backlog and brings the stories to the team to size and refine, and then the team commits to the most important work. Except now when you introduce a new feature to the team, you have to start by convincing them to pay for it:

You: “So, we need to integrate with Yawp’s restaurant review platform.”
Developer: “Interesting feature, Bob. Tell me why I should spend my valuable time and money building this.”
You: “Well, we have a partnership with them and …”
Developer: “But won’t people just go directly to Yawp instead of going through our app?” (glances at smartphone)
You: “We don’t think they will … I really …”
Developer: “Do you have any data to support this hypothesis?” (looks distracted, grins at tester)
You: (flustered) “Well I could get something together.”
Developer: “Great, get back to me when you have something.”

and … scene. Ouch. Truly the darkest timeline.

But Seriously

If you were able to sell – I mean really sell – your feature to the development team, how committed do you think they’d be? Would they put in that extra effort to get over the line? Sure they would. How likely would they be to just deliver you something “pretty good” that is technically correct but just doesn’t wow you? Not very, right? After all, it’s their money riding on the outcome.

And what do you think they’d do if they had a different idea, maybe even a better idea? You know that one: They’d be sure to tell you and you’d listen! If you have money, people listen whether the ideas are good or not 🙂


Well, we’re back in the real world. Phew! Shake it off, Taylor Swift, it wasn’t that bad. No one is really going to force you to sell the team on the value of your features. But you really should, shouldn’t you?

bored developers

If your team isn’t sold on the value of the work, it’s your job to convince them.

It’s The System, Maaaan!

Battleship Control Room

Do the modes of control in your workplace encourage dysfunctional team behaviors?

For those of you working with Agile development teams, here’s a question:  Are the behavior patterns you see in your teams because of the personalities of the team members, or because of the structures the team is operating within?  Think carefully …



Out Of The Mouths Of Babes

Recently I was driving my 4th grade son home from school when we were blocked by an accident in my neighborhood. Our streets are very narrow and people park on the street instead of in their driveways for some reason, so you have to be careful passing traffic going the other way. This particular day, a school bus and a car going around a curve in opposite directions had sideswiped each other and were totally blocking the street while waiting for the police. No one appeared to be hurt, so we turned around to make a 2 mile detour to get to my house the back way.

During the drive, I said to my son, “Wow, I hope no one’s hurt.” Then I asked him, “So … I wonder whose fault it was?” I was thinking about the bus driver and the car driver, but he immediately said, “Whoever designed the road. It’s way too narrow.”

Hmm … good point. Maybe both drivers were doing their best, and the system constraints set them up for failure. Can we relate this back to Agile teams in some way?

A Bit More About Why People Do Stuff

Around the same time this happened, I listened to an episode of the excellent Invisibilia podcast called The Personality Myth (synopsis here). I was already thinking about systems inducing behavior in people, but this discussion went even further to talk about whether people even really have consistent personalities! That is, if you think about people you know, maybe they only seem consistent because you encounter them repeatedly in more or less the same situations: at work every day, as your spouse at home, as a friend you play tennis with, or whatever. You’ve probably had the experience of seeing someone you thought you knew in a new and unexpected way. One person can be a quiet software tester at work, a community leader, music teacher, protester, party animal … or someone might seem stable but change dramatically under financial, work, or social pressure.

The discussion about this in psychology is called the Person-situation debate (Wikipedia):

The person–situation debate in personality psychology refers to the controversy concerning whether the person or the situation is more influential in determining a person’s behavior. Personality trait psychologists believe that people have consistent personalities that guide their behaviors across situations. Situationists, opponents of the trait approach, argue that people are not consistent enough from situation to situation to be characterized by broad personality traits.

The podcast talks in part about a hardened criminal who becomes an expressive ballet dancer when exposed to a new set of expectations. So surely we should be able to change our Agile environments and get different results out of our teams, right?

Refine Your Agile Experiment

Agile asks us to continuously inspect and adapt not just the product we’re building, but also the process itself. Teams do this via holding retrospectives and acting on “things to try”, but often they are more focused on technical or mechanical changes rather than influencing behaviors. They may also stay away from certain topics because they perceive them as sensitive or otherwise off limits. Guess who gets to worry about those things? You do! Here are just a few things that can significantly affect how teams behave:

Measuring teams against each other. It’s really tempting to look at story points or actual hours and use those to compare teams. Don’t do this. Story points normalize over time for individual teams, but not across teams unless there’s a lot of cross-pollination of members and ideas. And teams’ “actual hours” are often … er … highly creative retroactive estimates. As soon as teams think you’re gauging them like this, they will start overestimating everything to protect themselves. Instead, look at the big picture. Is each team delivering obvious business value? Do they always burn down 100% of their committed stories? How do their features look? Do they generate lots of production bugs or later rework?

Measuring individuals instead of teams. If you want your teams to jealously guard information and little architectural fiefdoms, and point fingers when things go wrong, the best way is to measure each person on a team as an island unto themselves. If instead you want your teams to hold each other accountable and work together to get things done despite individual hurdles, make it clear that success or failure happens at the team level and keep that focus for things like rewards and performance reviews. Obviously there will be occasions where someone just isn’t a good team fit, but more often members of a high-functioning team will actively strive to support each other and fill in skill gaps so that they can deliver more consistently.

Chaotic or inconsistent process. Scrum (and Agile generally) is about rhythm and predictability. Plan, execute, review, repeat. Over and over every couple weeks, forever. Take advantage of that rhythm by doing things the same way you did last time – except of course for things you decide to change as part of your retrospectives. Is your planning day always on Mondays (for example), with opening and closing ceremonies at the same time? Do stand-ups start at 9:30 am in the same spot each time? Is backlog grooming every Wednesday at 4 pm? Do you have a standing invite list for sprint reviews? Are retrospectives done before the next sprint starts? Are you insulating the teams from random production issues somehow, by using a support team or accounting for support time in planning? The answers to all these questions should be “yes”! For everyone on your teams – developers, testers, Scrum Masters, Product Owners – executing on the current sprint should be the number one priority. If it truly is, you should be able to create a reusable template for each iteration and let other non-sprint stuff live in the gaps. If the sprint stuff is what’s living in the gaps, you have a problem.

Lack of solutions from management. Teams get asked to do a lot. I haven’t yet seen a sprint where the Product Owner starts out by asking the team to do 80% of what they did last time. It’s usually a down-to-the-wire negotiation during planning, and the team decides to “go for it”. Then stuff happens – sick days, production issues, technical surprises – and they push through all of these, or try to anyway. But they also need the system to work for them, which means listening to their concerns and acting on them as needed. Did they work too many hours last time? Did we spring a feature on them at the last minute? Are they still fiddling with old work while trying to start on a new goal? Do they have the right development machines and software tools? How about work space issues like chairs, ergonomics and noise level? Nothing’s more demoralizing to a team than knowing what’s wrong and feeling helpless to change it. You’re supposed to be helping build self-directed, empowered teams – so get to it!

Lack of a clear vision. Most people will work harder and smarter if they are part of a compelling story. Product Owners take the wheel here – hmm, will “take the wheel” make sense in 30 years when all cars are self-driving? Anyway … the vision for a team needs to start at a high level and zoom in to the current time and scope:

  • Where is the product going?
  • Where is the product going in the next quarter?
  • Where is the product going in the next release?
  • How does my team fit into the vision for the next release?

Teams need to understand this vision and believe in it. They need to see their work get released and used by actual customers. They need to hear feedback from those customers in some way, the more directly the better. If teams do a competent job but don’t seem to have any fire, and rarely deliver any brilliant insights, it’s a good bet they don’t buy into the vision.

In Closing

I’d like to stress here that I’m not saying that individuals are helpless pawns whose actions are determined solely by environmental factors. We expect professional software teams to succeed in the system of which they’re a part, even as they try to push and pull it into a form that suits them. But as a leader you can have a disproportionate effect on that system and can accelerate positive change. So next time you see unwanted behaviors in your teams, please at least think about whether the problem might not be with the individual players, but with the rules of the game.

Definition of Ready (to be a robot)


Robots are cool, but they don’t get to make important choices.

Most agilists are familiar with Definition of Done (DoD): a team works together with the Product Owner to agree on a set of criteria that they can all point to and say “a story is complete when this list is checked off”. DoD can get pretty elaborate, including automated testing, documentation, bug rates, and so on. Teams don’t always hit their DoD with every story, but it’s a shared goal and reduces debate over what “done” really means. The value of a Definition of Done seems pretty obvious.

Definition of Ready (DoR) is the natural companion to Definition of Done, but it’s used maybe a bit less often. It lists out all the characteristics a story should have before the team accepts it into the sprint. It’s most helpful when teams struggle in their collaboration with Product Owners, business analysts, UX specialists, or other dev-team-adjacent roles. It says, “look, we’re eager to make a firm commitment and get started on this work, but we can’t just wing it. We need good acceptance criteria, and need to have talked about the stories enough to feel like we know what you want and how long it might take. We expect some challenges and surprises, but there’s no reason to be totally unprepared.”

Again, the value of a good Definition of Ready seems apparent. But I recently saw a DoR that looked something like this:

  • Acceptance Criteria detailed enough to be the basis of a test plan.
  • All UI wireframes completed by the UX team.
  • All text content finalized and translated.
  • All input validations detailed and complete.
  • System designs complete and finalized by the architecture group.

… plus all the usual stuff about sizing, review with the Product Owner, and the INVEST story characteristics.  Seems good, right?  I thought so at first too.

So, What’s the Problem?

The team with this Definition of Ready had a few notable characteristics:

  • The Product Owner and adjuncts (BA, UX) struggled to get things ready in time even though they were clearly trying.
  • The team was quick to point to missing DoR items as a reason for problems getting stories done and done well. “Well, the error messages weren’t provided.”
  • There was an over-dependence on design “spike” work prior to the sprint, often by different people.
  • Team members often complained that the work was boring or cookie-cutter and that there was no room for creativity.

What if I paraphrased the team’s DoR like this: “Before we start to work on these stories, we want them to pass through a series of gates – Product Owner, UX team, and architecture team – so that everything is finalized and we can be 100% sure in advance we know exactly what to build”? Hmm, what’s that sound like? Starts with “W”, has “RF” in the middle, and ends with “L” … no, not “Winterfell”. Waterfall!

How Did This Happen?

The team certainly didn’t mean to ask the business to spell out their work for them to that degree. They were reacting to some common problems that spring up in teams, mostly around communication. This team was pretty disconnected from the customer and the product vision, and wasn’t getting involved in any of the brainstorming and back-and-forth debate about features and how they should work. In addition, the organization was under a lot of pressure to deliver a lot in a short time and was reluctant to give the development teams an open license to be creative; instead, people in various named roles were expected to provide 100% of the ideas in their space. Finally, communication during sprints was unreliable because of how busy everyone was with design for the next feature, conferences, customer surveys, meetings, and tons of other stuff.

In this environment, the team had been left in the lurch more than once. Three days left in the sprint, and no one to answer a question. Lots of “we actually meant this; can you squeeze in that change?” Bombshells, curve balls, the works. And despite all this, a real quickness to blame the team any time a sprint didn’t burn down 100%. They went into defensive mode and traded the joy of creativity for the certainty of detailed requirements.

The Fix

There’s no exact right amount of detail to demand before accepting a story into a sprint. We’ve all heard that a story is an invitation to a conversation. That conversation should certainly start before the sprint, in story sessions, backlog grooming, and high-level design white-boarding. But it absolutely must continue into the sprint as the team begins to grapple with the details and has early builds available in test environments. That means that the Product Owner needs to be available throughout the sprint, which is a basic Scrum rule that is often broken to varying degrees. It also means that the team should have more authority over technical decisions and should not need be overly reliant anyone outside the team to give them answers. Remember, an ideal Agile team has the skill set to deliver a feature on their own. They should make a plan to own the work themselves and pull in auxiliary resources as needed instead of waiting to be given a complete instruction manual. If those auxiliary contributors have daily, strong, and open communication with the team, the team can get comfortable with a bit more ambiguity going into a sprint. I feel strongly that this makes for a healthier, happier team that is able to really deliver the spirit of want the business wants, and more often than not surprise and delight the Product Owner with brilliant solutions to the business problems posed to them.

I’m not saying to throw out your Definition of Ready, if you have one. Just don’t let it be a substitute for continuous communication or for trusting your development teams to make some decisions in flight. And teams – don’t write all the creativity out of your job.

Decomposing Product Owners

Despite the title, this has nothing to do with a horde of zombie product owners shuffling through the streets in search of Scrum teams.  I want to talk a bit about how Scrum defines the Product Owner role and how this can differ from real-world product ownership.  Specifically, let’s look at the responsibilities of the Product Owner and think about how organizations might end up handing parts of the role to someone else, and what the effects might be.  Finally, I’ll talk about how we might influence an organization to move towards defining more by-the-book Product Owners, or failing that, how we might ensure that the people who together compose the role are at least working together effectively and presenting a unified face to their teams.

Wait … Who Is The Product Owner?

Several years ago I did some basic Scrum training for new Scrum Masters in an organization.  Scrum was up and running within the team, but I saw some possible dysfunctions, so I structured the training like this:   First, I would explain some role, ceremony, or artifact as I understood it, including the value added by it; then, I’d ask the new SM to compare that definition to what he or she saw within the team.  Was everything A-OK or were there differences?  For any differences, did they represent a conscious choice to improve the process a la the “ha” of “shu-ha-ri”, or were they problems to be solved?

We were chugging along and generating insights until … we got to Product Owner.  I talked a bit and presented a basic list of PO characteristics like this:

  • Owns the product backlog and works daily to refine it
  • Understands the market and where the product is going
  • Provides clarity of purpose to the team: sprint goals, release plans, etc.
  • Is available to the team on a daily basis
  • Respects the team’s focus during sprints

I should note at this point that the organization had classic Product Managers who had received some general Agile and Lean training and had been given the PO role, but retained the original PM title.  In addition, there were business analysts who worked in the backlog and did grooming with the teams, plus a Project Manager overseeing the various teams, functional managers, and a UX lead who had probably the most frequent and detailed contact with users (If you’re in a large company that started waterfall and then went Agile, this may sound familiar).

Anyway, at the end of this brief summary of the Product Owner role I asked a budding Scrum Master, “So, based on this, who would you say is our Product Owner?”

(pause … gears turn)

“Um … I dunno … [names Project Manager]?”

Well that’s not ideal, is it?  We had a couple of PMs who clearly owned the product and prioritization, and teams of developers and testers who were more than a bit fuzzy on how the various business-facing roles work.  As you might imagine, I observed quite a bit of churn around prioritization, requirements, and vision.  And not the good kind of churn: no homemade butter was produced.

All of the people in this story were smart and dedicated and had a pretty good relationship with each other, but somehow the teams were performing less than optimally.  They generally got the requested work done, but the creative spark and exuberant collaboration you’d hope to see in a Scrum team was not quite there.  So let’s look a bit more at how the Product Owner role can be delegated or diluted and what that might mean.

Product Owner vs. Product Manager

A lot has been written on this topic, so I won’t linger too long here, but I like to see Product Owners who operate close to the metal: They’re in the grooming meetings, they know the agile tools (JIRA, Rally, TFS), and they roll up their sleeves to rank a newly found bug against the upcoming stories.  The farther up the pyramid they are in the company, the less time they tend to spend rubbing elbows with the team, and that can lead to a “development versus business” mentality where the development teams feel like “they” pressure us into unreasonable commitments, and the product management organization feels like the team is not fully committed and is disconnected from the business’ needs (probably because they are!).

Just like some teams tend to place the Scrum Master hat on a tech lead, it’s tempting to give the Product Owner title to a relatively high-ranking person.  That’s not really necessary though; the PO just needs to have enough delegated authority to make priority calls as they arise.  Much more important is the physical and/or mental proximity to the team, and the ability and desire to rank work at the story and bug level.

Product Owner vs. Business Analyst

Product Owners have a tough job.  They’re expected to really understand customers and the market, which probably means flying to conferences, sitting in marketing calls and user feedback sessions, and the like.  But they are also supposed to show up for Scrum ceremonies, dig into the minutiae of the backlog, and keep up with the progress of the current sprint.  How is that possible?  I know that when I was a development manager and took on the PO role on top of that I spent at least 2 hours a day, every day typing stories into JIRA, writing acceptance criteria, and creating mockups … all before customer meetings, strategy sessions, and more.  I made myself very approachable to the development team, and they had questions.  Boy did they have a lot of questions.

Given all this, some companies hire business analysts to handle the detail work of breaking features into stories, writing out acceptance criteria, and the like. But the BAs typically don’t have authority to prioritize the work or make calls on functionality.  If they are the ones doing grooming sessions with the teams, that means there’s a lot of “let me get back to you on that” or “I’ll run that by [product owner].”  This doesn’t have to be game-breaking, but it’s a slower feedback loop than direct PO-to-team discussion, so it’s something to watch.

Product Owner vs. True Power

By “true power”, I mean “who really makes the calls?”  Is it the VP of Product Management?  Senior Product Owner?  Someone in the development organization?  Sales?  One of the Product Owner’s key jobs is to manage directional push coming from anywhere inside or outside the organization.  Unless the PO is also the CEO (not likely), that means he or she needs to absorb all those wants and needs and make sure the backlog paints a true picture of what is most likely to be coming up next.  If those with true power are going around the PO and setting other priorities for teams, it creates confusion and disorder.  It’s up to the PO to manage stakeholders and keep that from happening.

Out of Many, One

Let’s finish up by going back to the anecdote of the budding Scrum Master who couldn’t point to a single person who met the criteria of Product Owner.  What could we do to fix this? It might not be feasible to snap your fingers and realign the job responsibilities of the PO, BA, UX, and/or project manager, but small changes can make things a bit more clear.

The Product Owner should articulate the product vision to the team every sprint.  If the PO isn’t available every day, he or she should show up to sprint planning with a compelling story about what the team is building and why.  This shouldn’t take long and provides the purpose the team needs to get energized.

The Product Owner should delegate some authority.  An engaged development team has a constant stream of questions for the Product Owner.  If the PO can’t commit to same-day responses on most questions, he or she can delegate (to a BA or other proxy) to give the team a better contact point.  But this person needs to have some true power to make decisions that won’t get revoked as soon as the PO is back in the office.

The Product Owner should review stories for the current sprint early and often.  I’m assuming here that the PO shows up for planning and the sprint review – if that’s not happening it certainly needs to.  But the sprint review or demo is too late for clarification.  Even a globe-trotting PO should be able to VPN into the test environment from the road and play around with features that are under development, so that small corrections and clarifications can be made in flight.  The team can facilitate this by adding “Product Owner has had the chance to review the work” to the story-level Definition of Done and proactively notifying the PO when stories are up and working.  Note the wording– “has had the chance” means the team offered the work for review, not that the team waits for the review to close the story.  If the PO doesn’t get to it and gets a nasty surprise at the sprint review, well … revisions go in the next sprint.

Present a united face to the development team.  This is the most important.  A PO who has other people helping to guide the work for the team owes the team clarity on how all the roles fit together.  This means frequent repetition of whatever arrangements have been made:  “Hey everyone – I’m going to be at the Business Success Summit next week; I’ve asked Susan to handle any UI questions or priority calls.”  Ideally the PO and friends also appear together at key points.  It might be obvious in the PO’s head, but standing in front of the team along with the business analyst/project manager/whoever and saying “yes, this is the vision; yes, we are all in agreement” can be very powerful.

In Closing

I hope this has been helpful.  I truly believe having a single product owner who ticks all the PO boxes is the best and simplest arrangement, but I realize that in the real world the PO is sometimes decomposed into several individuals.  Think about whether any of the tensions and variations above match your current situation, and what you might do to move things back toward the ideal.  There’s power in realizing that problems exist, and if you can see them, it’s a good bet that others do too and that you can rally together to overcome them.