Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

• (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal

• (Optional) representative(s) from the Management Team – clarify the high level priorities

• (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items

• (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items. It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

• The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team

• Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research

• Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team.

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

Brain Teaser With a Hidden Lesson

I was on Google+ last night when I came across a brain teaser.  It took me about 20 seconds to figure it out.  On average, I'm finding others taking about 2 minutes. Others just gave up, getting angry with me for asking the question.

I have a theory for how long it will take you to figure it out.  The more empathetic you are, the less time it will take you. Counter to that, if you are more apathetic toward others, it will take you longer.

The question:

What is the number of the parking space containing the car?

So, how long did it take you?

---

A Lack of a Shared Understanding

Earlier this week, I facilitated a backlog refinement meeting.  In the past, the team was used to all of the requirements being completed (in advance) by the analysts. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding. We came into the meeting with everyone agreeing they were on the same page.  That was true for about 15 minutes. The more we talked, the more they realized they were looking at things from individual perspectives.

At the beginning of the meeting, we had less than 10 user stories, from an analyst's perspective. By the end of the meeting, we had a prioritized backlog with over 100 user stories at different levels of granularity.  It's not perfect and it's never done.  But, it's a start.  For the first time, developers and testers were engaged at the beginning.  At LeadingAgile, we call this the Product Owner team.  When the highest priority stories get to a "ready" state, they will be pulled into a delivery team's queue.  Until then, we need to answer some of the more complicated questions, mitigate risk, and achieve that shared understanding.

Image Source: Based on hand drawn image from Pictofigo

How to be Successful with Agile at Scale

Ever asked yourself how you could be successful with Agile at scale? Let me show you how we've done it at LeadingAgile. In this one hour session that I presented to the PM Symposium in Washington DC, I explained how we've been successful by focusing on culture last and predictability first.

New Agile Training Classes Announced

Though I've been doing Enterprise Agile Coaching with LeadingAgile for over a year now, I haven't been doing a lot of training (or blogging).  I've been sticking to agile transformation work and the occasional private class.

Well, it's time for an update.  Dennis Stevens and myself co-authored the International Consortium for Agile (ICAgile) Agile Project Manager learning objectives back in February.  The result was a solid certification even a PMP could respect.

New Classes and Locations

LeadingAgile has decided to offer more public training.  We're offering classes in Atlanta, Denver, Orlando, and Washington DC.

Scrum

Certified ScrumMaster certification class

Certified Scrum Product Owner certification class

PMI

PMI Agile Certified Practitioner (PMI-ACP) certification prep class

ICAgile

Fundamentals of Agile (CIP certification awarded)

Agile Project Management (to be announced)

---

Are in interested in some public training?

Send me an email and I'll get you a special discount code.

---

Kumbaya Yourself into an Agile Enterprise

Best quote of Agile 2013 award goes to Dennis Stevens of LeadingAgile.  In a well received session by Dennis and Mike Cottmeyer, they discussed the topic of gaining support for a sustainable Agile transformation. [follow the link to the presentation].  When fielding a question about taking a culture first approach, Dennis responded: What are your thoughts?  Culture first or last?

---

Getting Teams to Deliver Predictably

As recently as this week, I've been involved in conversations with customers about how we can help make their teams deliver more predictably.  How can they meet commitments on all levels of the organization, including project, program, and portfolio? Well, it's not easy.  There is no silver bullet that is going to allow you to align the organization overnight.  I do, however, have one recommendation:  Stop trying to maximize the utilization of your people.  I know some are going to find that hard to understand.  To maximize value throughput, you need to keep your people as busy as possible, right?  Didn't Henry Ford do it that way, when he had cars coming off the assembly line at three-minute intervals?  Actually, no, he did not.  What he had and what you need is a balanced system.

Henry Ford did not have everyone working at 100% utilization.  If everyone worked at 100%, the result would have been congestion -- bottlenecks within his (assembly) system and the production of excessive parts inventory.  Instead, one of the many things he did was focus on limiting lead times.  That's the time something waits before an activity happens.  By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).

When trying to get your teams to delivery predictably at your organization, let's look at this from a 100,000 foot view:

• Understand Current and Potential Capability and Capacity
• Understand the Delivery System and Establish Goals
• Balance Capacity and Capability with delivery throughput
• Monitor Performance

That is how you establish predictable outcomes.

No let's look at this with some detail.

Understand Current and Potential Capability and Capacity

You've probably heard the analogy of a freeway being a value delivery system.  If not, let me draw the parallels.  On a freeway, we don't care about utilization; we care about throughput. That is, we don't care how many vehicles can fit onto the freeway. We care how quickly we get from point A to point B.  Measuring the capacity of the freeway is not going to directly help us. Measuring the throughput will.  For those who follow Lean Startup, these are referred to as vanity metrics and actionable metrics.

Actionable metrics can lead to informed decisions and subsequent action.  Example, I know how fast the vehicles travel on a given freeway, therefore I can plan accordingly to arrive on time.  Vanity metrics show that you're measuring things, but they really aren't helping you. You need to measure the right things.  By measuring the capacity of a freeway and then trying to fully utilize it would be foolish.  Strangely enough, I see organizations do that with their people all the time.  They try to keep them as busy as possible.

Understand the Delivery System and Establish Goals

We don't build bigger freeways so they can hold more vehicles.  We build bigger freeways because we're not smart enough to figure out how to limit the size or amount of vehicles on them at the same time.  The fewer or smaller the vehicles on the highway at the same time, the faster everyone moves along.  To increase throughput (speed) on a freeway, you need to increase the ratio of space utilized by a vehicle relative to the total space of the freeway.  If we could increase the (distance) buffers between the vehicles, we'd have fewer start and stops along our commutes. Once we hit higher utilization rates, things dramatically slow down until we have traffic jams.

Balance Capacity and Capability with delivery throughput

It's the same thing with knowledge based systems!  Exceed a 70% utilization rate and you'll begin to see dramatic performance decreases.

One thing that I have seen that is bringing it together is enabling teams to make their own commitments.  Once they have a sequenced queue of work and all the people necessary to complete that work, allow them to commit to, start, and then finish it.  You should begin to see the flow of value start to emerge.  Don't pull people from the team to give them "busy" work.  Don't push extra work on the team to keep them busy.

Monitor Performance

You can tell if your people are over-utilized by measuring the lead times.  If their work is properly sequenced, and they limit the size and volume of work they agree to do at any given time, the result should be minimal delays.  If you want to go faster, you may have to change the system.  Measure how long it takes to get something through your system.  Reflect on that.  Were there any dependencies on other people or resources that slowed you down?  Did you have your people over-utilized?  Was the work you committed to too big?  Look for an area of possible improvement, address it, and run work through your system again.  Did the lead time get shorter?

Going back to the commuting analogy, for those doing the driving, understand the conditions and know the optimal start time to begin your commute in order to avoid delays and arrive at your destination without breaking any laws.  For those asking for arrival commitments, respect what the driver tells you.  If you don't, you'll find people doing things like driving on the shoulder or illegally speeding in the express lane, just to arrive on time.  Sooner or later, there's going to be an accident.

Originally published on the LeadingAgile blog

My Perspective on Remote Work

The proclamation by Marissa Mayer last month, informing Yahoo employees that working from home is no longer an option, really seemed to bring an important conversation front and center. The memo that started this firestorm stated in part -

"To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices... We need to be one Yahoo! and that starts with physically being together."

I've worn a lot of hats over the years.  In each instance, there has been a common goal:  Be as successful as possible.  Being "successful" is unique to every situation so that's why I include "as possible".  But when you add happiness to the equation, what does that mean?

If you are in a job where you are rapidly iterating a product and continuously collaborating with others on your team, being face-to-face or side-by-side with your teammates will provide an opportunity to be as successful as possible.  Being collocated is no guarantee for success but being distributed (dislocated) is going to certainly limit your chances.  Leaders should focus actions more on making their companies, projects, or products successful and less on trying to make employees or teammates happy.

Now, don't get me wrong.  I'm not saying we shouldn't be empathetic to the needs of others.  I'm just saying there comes a point when you need to look at the costs and the benefits of remote work.  If the team is not realizing its potential, because one or more of them are working remotely (because they want to and not because they have to) we have a misalignment of goals.  Why would they sacrifice potential success for their personal comfort?  Well, businesses are trying to find ways to incentivize their employees. They hope that by incentivizing then, they will be happier and more productive.  But see, that is part of the problem. There is a belief that the incentives will make them happy.  Happiness is one of the byproducts of satisfying work, which can be derived from feelings of mastery, autonomy, and purpose (link to talk by Dan Pink).  I believe (in some cases) the work-from-home incentives will have a negative affect.

When companies hire us, they are NOT hiring us to make people's lives better.  They are hiring us because there is value locked up in these companies and they are unable to produce.  They are hiring us to help them unlock that value.  Period.

What's one of the first things I would propose if I coached teams at Yahoo? Bring the team together, face-to-face or side-by-side.  The only thing I disagree with in the Yahoo memo experpt  is where it states "…we are all present in our offices…"  I propose they get out of the private offices and into a team space.

Balanced piece about the pros and cons of working at home on Fast Company

Image Credit: Pictofigo