The New New Product Owner: The Product Marketplace Expert

In my previous post, I discussed the 7 focus areas for the New New Product Owner, as well as the “Product Value Maximizer” focus area.  In this post, we explore the “Product Marketplace Expert” focus area.

The New New Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster. Note here that the New New Product Owner may or may not be the one doing the legwork of gathering the marketplace data(they might delegate), but they should certainly be aware of the market research.  Often times the New New Product Owner will delegate to others or to automation to aid them in obtaining the market data.
Note that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to gather the marketplace data.

With IT software, the market data will often include how the LOB(Line of Business) uses the software, as well as understanding the business function that the LOB executes on.  Heavy interaction with those in the LOB will usually yield this data, or again, the New New Product Owner might delegate or rely on someone in the LOB to supply her with that data.  A good starting point for gathering this data is understanding who your key stakeholders are.

Additionally, the New New Product Owner should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

The New New Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Management, Product Backlog Refinement, and in Sprint Reviews.

Knowing the market for your product can help you fulfill another key focus area, being The Product Visionary.

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.
The 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 said 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:

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

Other Good User Story Links

• User Stories article on Agile Atlas (New! March 2013 – I co-wrote this one — great article if I do say so myself!)
• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• To see more information on grooming user stories, see:
  • What does Product Backlog Grooming Look Like?
  • Tips for Effective Backlog Grooming
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.
• I wrote a skit for a presentation I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:
  • 

    Script_UserStoryUtopia.pdf

    • Details
    • Download
    • 82 KB
• For good advice on how to split User Stories, see Richard Lawrence’s Story Splitting Flow Chart.
• For a good article on why to split User Stories, see Mark Levison’s Story Splitting, How Small is Enough?

A Visual Diagram of the User Story Life Cycle

This blog post is now deprecated.  Please see the new updated blog post:

https://scrumcrazy.wordpress.com/2013/06/13/new-and-improved-user-story-lifeycle-diagram-free-creative-commons-pdf-download/

 

My Preferred Agile, Scrum, and XP Resources

If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

My Preferred Resources

All are in order of my personal preference in each category.

---

Scrum

1. The Scrum Guide (Must read for all)
   • http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf
2. Deemer, et al. “The Scrum Primer”
   • http://www.scrumprimer.com/
3. Cohn’s _Agile Estimating and Planning_ (Must read for Scrum Masters)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Pichler’s _Agile Product Management…_ (Must read for Product Owners)
   • http://www.amazon.com/Agile-Product-Management-Scrum-Addison-Wesley/dp/0321605780
5. Cohn’s _Succeeding With Agile…_ (Must read for Scrum Masters once they have a few Sprints under their belts)
   • http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364
6. Kniberg’s _Scrum and XP From the Trenches_ (Note that there is a free PDF download of this book if you register with InfoQ – something I recommend anyway)
   • http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
7. Derby/Larsen’s _Agile Retrospectives_
   • http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649

---

XP (Extreme Programming)

1. Jeffries’ “What is Extreme Programming?”
   • http://xprogramming.com/book/whatisxp/
2. Jeffries’ _Extreme Programming Installed_
   • http://www.amazon.com/Extreme-Programming-Installed-Ron-Jeffries/dp/0201708426
3. Koskela’s _Test Driven…_
   • http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850
4. Martin’s _Clean Code_
   • http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
5. Feathers’ _Working Effectively With Legacy Code_
   • http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
6. “The Rules of Extreme Programming”
   • http://www.extremeprogramming.org/rules.html
7. Wiki entry on XP Practices
   • http://en.wikipedia.org/wiki/Extreme_programming_practices

---

Agile/XP Testing

1. Summary of Lisa Crispin’s Presentation to Agile Denver on Test Automation
   • http://properosolutions.com/2011/10/the-secrets-of-successful-test-automation/
2. Cripin’s “Using the Agile Testing Quadrants”
   • http://lisacrispin.com/wordpress/2011/11/08/using-the-agile-testing-quadrants/
3. Crispin/Gregory’s _Agile Testing_
   • http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
4. Crispin/House’s _Testing Extreme Programming_
   • http://www.amazon.com/Testing-Extreme-Programming-Lisa-Crispin/dp/0321113551
5. Cohn’s “The Forgotten Layer of the Test Automation Pyramid”
   • http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
6. Osherove’s _The Art of Unit Testing_
   • http://www.amazon.com/The-Art-Unit-Testing-Examples/dp/1933988274

---

User Stories (which originated in XP)

1. My “User Story Basics” article and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/User+Story+Basics
2. Cohn’s _User Stories Applied_
   • http://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685
3. Cohn’s _Agile Estimating and Planning…_ (Chapter 12: Splitting User Stories)
   • http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
4. Lawrence’s “Patterns for Splitting User Stories”
   • http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

---

Special Agile Topics (if applicable)

1. Deemer’s “The Distributed Scrum Primer” (If some of all your team is remotely distributed)
   • http://www.goodagile.com/distributedscrumprimer/
2. My article entitled “The Role of Managers In Scrum” and all of the links at the bottom of that article
   • http://www.scrumcrazy.com/The+role+of+Managers+in+Scrum
3. Larman/Vodde’s _Scaling Lean Agile…_ (If your Agile transformation involves a very large organization)
   • http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961

User Story Basics – What is a User Story?

What is a User Story? I’m glad you asked!

First of all, it’s important to say that User Stories are not a part of Scrum as defined in the required practices in the Scrum Guide. User Stories are but one way to represent Product Backlog Items in Scrum, and while it is the most popular method used, it is not the only method. Still, though, I would like to remind you that the User Stories practice is totally independent of Scrum, and thus it is not defined by Scrum. As such, everything else in this post is about the User Story practice and not Scrum itself.

Beware the common misconception!

There is a common misconception in the industry that a User Story is a sentence like:

• As a <user> I want <some functionality> so that <some benefit is realized>.

THIS IS NOT A USER STORY!!! This is the biggest User Story trap in existence! See Trap#1 and #8 of my article on User Story Traps.

What is a User Story?

<Definition>
A user story describes functionality of a system that will be valuable to a Non Development Team(NDT) stakeholder of a system or software. User stories are composed of three aspects:

• a written description or short title of the story used as a token for planning and as a reminder to have conversations
• conversations about the story that serve to flesh out the details of the story
• acceptance tests that convey and document details and that can be used to determine when a story is complete

</Definition>

What do they mean by Acceptance Tests?

Typically, in the context of a User Story definition, we mean tests that are represented by conversations, textual descriptions, tables, diagrams, automated tests, and so forth. When these Acceptance Tests are applied to the completed, implemented User Story, all of the tests should pass, and will thus prove that the story has been implemented correctly. If some functionality was not covered in a User Story acceptance test, then it wasn’t a requirement for that particular User Story.

Technically, in the context of a User Story definition, an acceptance test need not be automated or implemented. At the minimum, it should be described conceptually. The test should then be executed in order to prove the story and get acceptance, whether that be a manual or automated process. If your conceptual acceptance tests are described by one or more automated tests, then that is generally a much better practice, but not absolutely required.

Acceptance Tests should be automatable about 90+% of the time, though again, it is not required that they be automated. Having said all of that, when teams strive for development speed and quality, very few get far along that road without automating a large portion of their acceptance tests.

Acceptance Tests, in the context of User Stories, are also sometimes called Story Tests, Acceptance Criteria, Conditions of Satisfaction, and Test Confirmations.

Ron Jeffries, one of the co-inventors of User Stories and Extreme Programming (where the User Story practice comes from), has a good article that also describes User Stories in a basic way.

When do these Conversations and Acceptance Tests get created?

Typically, this happens in weekly Product Backlog grooming(also known as a Story Writing Workshop, Story Grooming, etc) sessions, but can also happen informally. The most effective backlog grooming includes some stakeholder/user representatives, the entire development team, and a Product Owner (Scrum) or Customer(XP). These sessions happen weekly and usually last 1-2 hours each. The goal of the sessions is to get stories that are “ready”, meaning the team has a shared understanding of the Acceptance Tests, and has the vast majority of the information they need to implement(code) the feature. See What does Product Backlog Grooming Look Like? for more on that topic. Keep in mind that sometimes a single User Story will be discussed in 2-3 grooming sessions before it is “ready”, especially if there are open questions or complex logic involved.

Frequently Asked Questions

Should I use a User Story to represent bugs/defects in a system?
The short answer is “it depends.” If it is a legacy or deferred bug, then yes, and it should end up on the Product Backlog(story points assigned). If it is a bug that was introduced since Scrum/Agile was put in place, then no, and it should end up on the Sprint Backlog(no story points assigned). See One way to handle Bugs and Production Support in Scrum for the longer answer.

Where do I get more info?

• A User Story Checklist
• User Story Basics – The Longer Story
• To see what User Story Traps cause a lot of pain on teams, see User Story Traps
• To see how to make sure your stories are “ready” for implementation, check out The Definition of Ready
• To see more info on creating Acceptance Tests, see my Presentation – Story Testing Patterns
• To see how well your team is implementing the User Story practice, see the The Bradley User Story Maturity Model
• Ron Jeffries’ article: Essential XP: Card, Conversation, Confirmation
• The best book on the subject of User Stories, IMO, is Mike Cohn’s User Stories Applied.

Story Testing Patterns – My Recent Presentation at Mile High Agile

You can now find my recent presentation(along with all the handouts, etc), “Story Testing Patterns” on my website here:

http://www.scrumcrazy.com/Presentation+-+Story+Testing+Patterns

Feel free to add any comments here on my blog.

.

Scrum Guide 2011 – Backlog Grooming as a Required Practice

Intro

In my previous article, I give an overview of some of the interesting changes incorporated into the 2011 Scrum Guide. One of the most interesting changes in my view is the inclusion of Backlog Grooming as a required practice. In my Scrum coaching experiences, the one practice that seems to help beginner Scrum teams the most is backlog grooming. In some cases, the practice itself makes many PO related obstacles highly transparent, but transparency is what we want!

 

Backlog Grooming: The Red Headed Step-Practice.

I think that many beginner Scrum teams have trouble deciding on how best to transition to Scrum. They focus so much on the major practices (Product Backlog, Planning, Review, Retrospective), that they don’t realize that backlog grooming can ease some serious Sprint pain. This idea that the Sprint Planning Meeting is the first time we hear about all new backlog items is absolute nonsense, but that’s how the pre 2011 Scrum Guide read to a lot of people. Will there be late breaking backlog items that might be presented for the first time at the planning meeting? Yes, but it should be rare to very rare.

 

Third Time’s the charm…

I’ve found that most teams seem to have the highest productivity on implementing a backlog item when they’ve had a chance to discuss the item 3 times, with the 3rd time usually being the Sprint Planning Meeting for the Sprint in which it will be implemented. Each time a backlog item is discussed(with the whole Scrum team present), it is decomposed a little further and open questions and risks are identified. In between these three discussions, people should take action items to answer these questions and mitigate the risks. These action items are ones that often take days in duration to answer, for whatever reason (answers from stakeholders, technical deep thought and investigation, etc), but don’t take a lot of effort for each action item. Throwing all of these action items into a 2-4 week sprint means you’re putting these long duration tasks onto the critical path, and that’s just not productive.

 

My Coaching Style for New Teams

When I coach a team that is just beginning Scrum, I actually start with backlog grooming first. I usually pick a point on the horizon 2-3 weeks out and say: “Sprint 1 will start on date X, and between now and then, I want you to continue working how you have been working, except that we’ll have a few training sessions between now and Sprint 1 so that we can hit the ground running(or “Sprinting,” if you prefer). Much of the time in those training sessions is focused on good backlog grooming techniques (and usually User Stories and Story Testing). It all starts with requirements!

 

Experienced Scrum Teams are Not Immune

Other non beginner Scrum teams also never seem to get to the point where they do backlog grooming well. I think many Scrum teams plateau when it comes to implementing Scrum, and this is really unfortunate. As Jeff Sutherland suggests in the Enhanced Nokia Test (aka “The ScrumBut Test”), the huge productivity gains for Scrum teams are in the last mile of implementing Scrum. If a team never gets to that last mile, then the high productivity promised by Scrum is never achieved. If your team wants to get highly productive, then your team needs to get really good at backlog grooming.

 

In My Ideal World…

In my ideal world, a team will first see a backlog item at a high level in a Release or other high level planning meeting. They will then dive deep into the item during a backlog grooming session near the beginning of the Sprint before its most likely implementation, identifying requirement and technical risks, logic questions, and other things that get in the way of fully decomposing the item into acceptance (or story) tests. Then, the item might be lightly touched on outside the grooming when unknowns become known, or maybe again in a grooming session a few days before the next Sprint. Then, at the Sprint Planning meeting, there are only very minor unknowns about the item, and the team is well versed on what is trying to be accomplished by the item. Knowing what work will need to be done for the item means the team can better plan their work for the Sprint. They can front load risks, parallelize efforts (automating the acceptance tests is a good parallel effort), and visualize the critical path for this and other items.

 

Where to Find Out More

I’ve written a series of articles on Backlog Grooming. <shameless plug> I haven’t updated them for the 2011 Scrum Guide yet, but nothing much about the 2011 Scrum Guide changed the practice itself, so probably 97+% of the material is still applicable.

 

For my articles on Backlog Grooming, see:

• Why do Product Backlog Grooming?
• What does Product Backlog Grooming Look Like?
• Tips for Effective Backlog Grooming