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.

In Scrum, Who are the Key Stakeholders that Should be Attending Every Sprint Review?

The Scrum Guide requires that the Product Owner ensure that “key stakeholders” attend the Scrum Sprint Review, but who are these “key stakeholders”?

According to the Scrum Glossary, a stakeholder is “a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.”

Typically, they fall into one of three broad categories:

• The Users – The human people who actually use^1 the software product under development, to help them or the organization make more money or save money.

  • This could include a human compliance officer within a company, who is responsible for making sure that the software systems comply with government or financial regulations.
  • This could include the humans who support the operations or production support for the product.
  • Upstream/Downstream systems could also be considered “users” so long as we don’t forget the human end users of those systems. Don’t forget the humans!
    • Downstream reports are a good example of a downstream system” where you should definitely not forget the “human end user”, but there are other examples.

• The External Customers (doesn’t exist for internal products — see below) – The people responsible for paying to use the software product.

  • Only applies to externally sold or externally developed products
    • By external here, we mean, outside the company doing the development.
  • In a “software development for hire” arrangement(externally developed product), the client who engages the team would be the External Customer.
  • Sometimes the External Customers and Users are the same people — take TurboTax as an example, or a software product whose human users also make the decision to purchase said product.

• The Internal Customers – The people responsible for making the funding decisions for the software product development effort.

  • This is usually someone in Product Management(usually for external products) or someone in management in the Line of Business(usually for internal products) that is supported by the software product.
  • It could also be the CEO or CIO or similar roles at times.

There are probably exceptions to the above three broad categories. Also, don’t assume that the Product Owner can only consider “key stakeholders” as sources for requirements or good ideas. The Product Owner can work with anyone any time (possibly during Product Backlog Refinement and other activities) who can supply good ideas to capture more value for the product. Our discussion of key stakeholders here is just to understand how the “stakeholder” role in the Scrum Guide can be interpreted.

The key stakeholders are the people that receive a direct financial^2 benefit(helps them or the organization make more money or save money) from using the software.

One could also think of the management of the development organization as a stakeholder who should attend Sprint Reviews, certainly in replacement of any and all status reports and any and all other progress reporting for the Scrum Teams. If any Dev management asks for these things, the answer should almost always be something like “In Scrum, that information is communicated in Sprint Reviews, so let me get you on the invite list for that.” For Scrum “key stakeholder” purposes though, I’m not sure I’d call Dev management “key stakeholders.” or think of them as being “required” to be present(unless of course, they request status/progress reports).

In some cases, you’ll have so many “users” that it is not possible to have all of them in your Sprint Reviews. In those cases, try to get a representative sample of human users into your Sprint reviews(some companies pay for this kind of feedback from human users), and also utilize other feedback gathering mechanisms. (See “One PO Can Do it All!” in this product ownership article.)

Parting Words

I’m sure that there are exceptions to the above three broad categories, so feel free to let me know if you can think of some noteworthy ones, or maybe see if you can effectively place them under one of the three broad categories above. Talk to the Product Owner and make sure that they are ensuring that key stakeholders are are attending your Sprint Reviews, as their input is absolutely vital to the success of the product.

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.

———-

Notes:

^1 Rare exception — note that sometimes a software development team acts as a “Production Support Engineer” user, but this should only apply to features actually in the product(support logging might be a good example) that help with production support. However, the modeling of a human user who is on the software development team should not become a guise for so-called “technical stories” or technical practices. That’s not a real “user”.

^2 Rare exception — If the organization developing the software is a non profit, government entity, or charity, then instead of “financial benefit” or “money”, we might say “the societal benefit” instead.

Should I use hours to estimate my tasks in Scrum?

My new recommended “starter” “complementary practice” for new Scrum teams is to simply create tasks and use the “number of tasks remaining” for a burndown.  (I also usually recommend that they try to make it such that the vast majority of their tasks are roughly 1 day or less) I encourage them more to focus on PRI (potentially releasable increments), Sprint Goals, and achieving a moderately consistent level of skill at meeting their Sprint forecasts (used to be called “Sprint commitment,” it’s been re-named in the Scrum Guide).  I also caution heavily against trying to achieve perfect forecast accuracy as that’s a fool’s errand in complex domains.

Using hours for tasks can lead down some really bad roads, most notably:  Former PM’s turned SM’s and other organizational members who try to apply PMI tactics (100% utilization, tracking actuals, etc) tactics to complex software development.  By preferring “sticking to the plan” over “responding to change”, they are completely violating Agile and Scrum.

This same bad road can also lead companies into think that “schedule/scope/cost” is an optimum model for software development.  As far as I’m concerned, schedule/scope/cost is a dead, failed model for software.

Now, using hours for tasks doesn’t have to lead down those bad roads — but in my experiences, they usually do.  Let’s not forget, Scrum used to require hours for task estimation, many years ago, but the Scrum experiences of the wider community over 20 years has spoken on the topic — hours is not always optimum.  I would go farther than that and say, at the Sprint task level, it’s usually NOT optimum.

Given the above, I’ll leave it as an exercise to others to describe where using task hours might not lead down those bad roads.

_____
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com

New Courses from ScrumCrazy.com:

• Scrum For Executives
• Agile Requirements: Product Owner and Team Collaboration Techniques
• Scrum Product Owner: Techniques for Success
• Evidence Based Management for Software Organizations(TM)
  • Class for Software Development Managers and Executives

If you’re interested in any of our classes, training, or coaching services, feel free to contact us.

Scrum of Scrums is an event *of* the Development Team, *by* the Development Teams, and *for* the Development Teams!

Hello ScrumCrazy readers,

I’m proud to announce that my article on the “Scrum of Scrums” practice got posted on Scrum.org.

In the article I give some advice on excellence in execution of the Scrum of Scrums practice, and how the Scrum of Scrums has been misinterpreted my many to be a status meeting. It’s an event of the Development Teams, by the Development Teams, and for the Development Teams!

Please give it a look and give me feedback here or there. Feedback welcome!

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?

Daily Scrum Patterns: The Sprint Backlog at the Daily Scrum

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

“The Sprint Backlog at the Daily Scrum” Patterns

While it’s a popular and proven practice to <View the Sprint Backlog at the Daily Scrum>, it’s a controversial practice to <Update the Sprint Backlog at the Daily Scrum>, as the updating can detract from the true objectives and focus of the Daily Scrum in some situations.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

The Sprint Backlog at the Daily Scrum Patterns:

• <View the Sprint Backlog at the Daily Scrum>
• <Update the Sprint Backlog at the Daily Scrum>

Daily Scrum Patterns: Who Attends the Daily Scrum?

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

• All Scrum Patterns are displayed as such: <Scrum Pattern Name>.
• All patterns currently link to the same Daily Scrum Patterns Summary Chart, where you can find out more info about each pattern.

Who Attends? Patterns

According to the Scrum Guide, the Development Team must attend. With many teams, and especially Shu level teams, the <Scrum Master Attends>. It’s usually a good practice if the <Product Owner Attends> so that they can help the Development Team if needed, often times at <The After Party>. It’s usually not good if an <Authority Figure Attends> on a regular basis.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Who Attends? Patterns:

• <Development Team Only>
• <Scrum Master Attends>
• <Product Owner Attends>
• Anti-Pattern: <Authority Figure Attends>