Product Owner and the Scrum Team

No Comments

iiba baltimoreOn March 11, 2014, I presented a talk to IIBA Baltimore on the topic of the Product Owner and the Scrum Team.  I have to say, this was an awesome bunch of people to talk with.  You know you’re at the right place when they offer beer and crab cakes with dinner.  Gotta love Charm City!

The last 10 years of Agile have focused on the team. I believe the next 10 years of Agile will focus on the enterprise. That said, should the Product Owner continue to be a single person or does it need to evolve as well? Let’s cover the basics and then see how LeadingAgile has been successful at leveraging the Product Owner role at scale.

iiba promo code

As a thank you to IIBA, I was able to get a promo code for 50% off an upcoming Agile Requirements Workshop. The code “IIBA” is limited to only 5 seats.  Are you a business analyst in the Atlanta area or want to go visit some friends in Atlanta?  Take advantage of this limited offer.

Categories: Agile Tags: Tags: , , , ,

Cheat Sheet for Backlog Refinement

1 Comment
Backlog Refinement Meeting

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

A Lack of a Shared Understanding

No Comments

I am so glad we all agreeEarlier 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

Zero Cost Effect

No Comments

I had dinner with a colleague the other night.  I inadvertently quoted something verbatim from Dan Pink’s book, Drive. My colleague said if I liked Dan Pink’s work, I should read something from Dan Ariely.  So, I started on Predictably Irrational:  The Hidden Forces That Shape Our Decisions. Wow, this book is crazy!  I’m not going to go into any more details in the post other than a comparison of an experiment detailed in the book and something I’ve seen in the real world.

In the book, the author described an experiment on 34 Halloween trick-or-treaters. As soon as the children knocked on the door, they received 3 Hershey’s (each weighing about 0.16 oz.) and were asked to hold the Hershey’s they had just received in their open hand in front of them. Each child was then offered a choice between a small (1 oz.) and a large (2 oz.) Snickers bar, under a Cost Condition and under a Free Condition.  In the Free Condition, they could simply get the small 1 oz. Snickers bar (for free) without giving up anything or they could exchange 1 of their 3 Hershey’s for the 1 large Snickers bar.  In the Cost Condition, the children could exchange 1 of their .16 oz. Hershey’s for the small (1 oz.) Snickers bar or exchange 2 Hersheys for the large (2 oz.) Snickers bar.  They could also choose to do nothing but all of the kids chose to make an exchange.

Experiment Results

In the Free Condition, in which the small Snickers bar is free, demand for it increases substantially (relative to the Cost Condition).  The results demonstrate the attractiveness of zero cost.  People gravitate more toward options that do not require giving up anything.

Example of this on a project

At work, I’ve had a Product Owner (PO) who wanted to add items from the Backlog to the Sprint.  During sprint planning, the team basically added a buffer, to account for unforeseen events.  I know people are going to crucify me for this, but basically, the Product Owner always seemed to want to shift priorities of work mid-Sprint.  Rather than killing the Sprint, we added a buffer.  This would allow new work to be entertained without totally derailing the work already being completed.  Yes, we could have used Kanban and all of this could have been avoided.  But, Kanban wasn’t an option.

So, what happened?  I offered the PO a deal.  I could allow him to add a certain amount of work to the Sprint for free. When I did this, he usually asked for smaller deliverables (relative to other items on the backlog that were ready to work).  But, when I said some work would have to come off the table to pay for the new work, he always went big.  He would choose larger deliverables relative to other items on the backlog that were ready to work.

All I can say is we truly are predictably irrational.


Yes, the links to the books are affiliate links.