The New New Product Owner: The Product Value Maximizer in Scrum.

Preface:  In the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Product Owner role that have far reaching implications. In this article and the series that follows, I attempt to describe “The New New Product Owner” role in Scrum.

In a series of upcoming articles, I will detail the different focus areas that the modern Product Owner needs to concentrate on in order to fulfill their duties on a Scrum team.
POFocusAreas_NewNewPOThe New New Product Owner understands that she will likely need to execute these activities at different times, and that she might need to delegate to others in order to effectively produce software that maximizes ROI for the software development effort.

The first and most important focus area is for the Product Owner to be the “Product Value Maximizer.”  There are lots of way to do this, but 3 key steps are involved:

  1. Order the Product Backlog by (estimated) value.
  2. Work with the Development team to get small increments of value to market quickly, for feedback.  Release to market = in production, available to end users.
  3. Rapidly assess value delivery feedback from the market, and then start over again at step #1.

These three steps will ensure that the New New Product Owner delivers “the right thing.”

Note that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to get features into production quickly, and to assess whether we have “hit the target” with respect to value… or not.  This quick release to production, every few weeks, is a key aspect of Agile software development.

If you haven’t already signed up for our blog, be sure and sign up (upper left hand corner) so you will get the future articles on this topic!

In future articles, I will detail the remaining six focus areas for the New New Product Owner:

  • Product Marketplace Expert
  • Product Visionary
  • Product Release Decision Maker
  • Product Backlog Management Leader
  • Lead Facilitator of Key Stakeholder Involvement
  • Effective and Active Scrum Team Collaborator

For a high quality class that focuses exclusively on the Product Owner role(send your business stakeholders too!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.  We teach all over the USA.

User Stories – Focusing on Conversations instead of Writing – Gojko Adzic’s New User Story Book

In my recent article on telling user stories instead of writing user stories, I mentioned that many Scrum Teams focus way too much on documentation and way too little on good collaborations.

More support for this concept comes from the first chapter in Gojko Adzic’s new User Story book, Fifty Quick Ideas to Improve your User Stories.

User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions…. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made…. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations…Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

Gojko has been nice enough to publish the “Tell stories, don’t write them” chapter available completely free here!  It is also important to note, that this chapter is tip #1 in his book, as it really sets the stage for the best use of the User Story practice.

The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth another five minutes of your time to read Gojko’s free chapter, and be sure to share it with your teams and organizations too!

To maximize your Scrum and User Stories practice, bring us into your company to deliver coaching or our User Stories Class.

Focus on Telling User Stories, NOT Writing User Stories

Ebin Poovathany has written a wonderful article on how we should focus more on the verbal conversation aspects of User Stories rather than focusing too much attention on “writing” User Stories. I myself have written an article about this as well (See Trap #’s 1, 8, 10,and 13). It’s great to see that this topic is starting to get more attention in the industry.

As Ebin points out, using so called “User Story Templates” (“As a user, I want..”, “In order to…I want…”, etc) causes people to backslide into older waterfall habits, and creating the same old kinds of documents that we used to create in waterfall, along with the same old problems. He sad this is sad, and as a User Story proponent, I agree. It’s a horrible misunderstanding, but it’s rampant in our industry. The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth your five minutes to read Ebin’s article, and be sure to share it with your teams and organizations too!

To learn how to avoid User Story Traps and maximize your User Stories practice, see more info about our User Stories Class.

New and Improved User Story Lifeycle Diagram — Free Creative Commons PDF download!

I had a designer friend update my User Story Lifecycle diagram, and she did a fantastic job!  You can download the PDF here:  http://www.scrumcrazy.com/lifecycle

New and Improved Diagram:

UserStoryLifeCycle_final_lg

The Older Diagram(also still available at the above link):

UserStoryLifecyclexm

Other Good User Story Links

Bradley Bug Chart Referenced in Awesome New Scrum Book

The Bradley Bug Chart was referenced in an awesome new Scrum Book that is now on the market.

Background

I got an email from this guy named Rich one day who wanted to talk by phone and ask me some questions about the Bradley Bug Chart. A great collaboration ensued, and I incorporated some of his suggestions into my chart. A couple of weeks later, he asked me to review Chapter 1 of this book he was writing. I have some of the highest standards around, and I’m not easily impressed, but that first chapter was extraordinary! Through that one chapter, and the conversations with Rich, I realized this guy knew Scrum inside and out. I then reviewed and commented on a few more chapters. I get asked to do unpaid reviews often, but I only spend my time on things that I think are excellent for the Agile community. I’ve spent some time reviewing another book that hasn’t been published yet, and it too, is a great one for the industry in my opinion. More on that one when it gets published.

The Bradley Bug Chart Gets Called Out

A little while later, Rich asked me if he could refer to my Bradley Bug Chart in his book(see page 277), in a section on how to handle bugs in Scrum. I was ecstatic, in part just having my work get recognition, but it was also recognition from someone I highly respected myself. It was great. I also re-wrote some of the praise that I gave Rich on that Chapter 1 review as a quote for his book. Rich also ended up quoting me a few times in other parts of the book, particularly in the chapter on “Continuous Improvement.” I’m not trying to brag here, just sharing the satisfaction of seeing some of my hard work and learning as being objectively recognized in the community.

About the Book

Here is the quote I wrote for his book:

  • “Finally a book about Scrum from the Development Team’s point of view. Richard’s description of the best and worst ways to implement Scrum is priceless. The first chapter alone is one of the best descriptions of ‘Scrum done well’ that I’ve ever seen.” — Charles Bradley

I highly recommend his book for anyone working with Scrum and Microsoft Visual Studio/.Net technologies.

Here is the book:

PSDBook_Small

Small Caveat: Rich is and was a trainer with Scrum.org, and since our initial collaboration, Rich inspired me to become a trainer for Scrum.org as well. So, while none of this was true at the time of the above events, I wanted to mention that we are now both trainers for Scrum.org. I have no financial interests in his book, whatsoever, and my journey to become a Scrum.org trainer came after my review of his book. Thanks Rich!

New User Stories Article on Agile Atlas

I recently co-authored a new article on User Stories with fellow Scrum Trainer Mark Levison. I think it’s one of the better introductory articles to User Stories on the net, and having the credibility of the Agile Atlas is great. Ron Jeffries, the co-inventor of User Stories, was one of the main reviewers of the article, so that was a little intimidating. But, he gave it high praise and only suggested a couple of minor edits. The article is now my “go-to” article on an introduction to User Stories.

Here is the article: http://agileatlas.org/gasps/article/user-stories

Other Good User Story Links:

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

ScrumCrazy.com update:

  • Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
  • Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!
Follow

Get every new post delivered to your Inbox.

Join 387 other followers

%d bloggers like this: