User Stories: The Product Manager & The Development Team

If you’re being Agile, …

Sorry, it’s not about Agile but about customers and customer value. Let me start again.

If you’re using User Stories as the vehicle for product creation and improvements, the product manager and development team can both be best served if they share a strong understanding of the business rational and customer problems to be solved. The user stories act as the bridge between business goals and the value the product brings to the customer for all stakeholders on the business/product team. In Scrum, the product manager is often called a product owner. Depending on your business, the product manager and product owner could two people but for this article I assume they’re the same person.

In the 2016 Scrum Guide, the role of the Product Owner is defined as the sole person responsible for managing the Product Backlogand “is responsible for maximizing the value of the product and the work of the Development Team.”

This is usually where some people get the false notion the product owner does all the work to create and maintain the product backlog including, writing all user stories. At one company, I was confronted with the development team’s manager telling me, “are you trying to make us all product owners” when it was suggested the development team could help breakdown and write user stories. This is a common misconception of what the product backlog and the role of the Scrum product owner are all about. If one were to read a bit further, the Scrum Guide clearly doesn’t want this to be a one person band; “The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

The idea that only one person is doing the work is different from one person being responsible for the work. For example, as a parent, you feel responsible for the education of your child but although you help with homework, the larger proportion of the educational tasks are left in the hands of others. As a parent, you are responsible yet trust the education of your child to trained and experienced experts. So too is the work of populating, refining, and prioritizing the product backlog.

“Business people”

“Business people and developers must work together daily throughout the project.” – Principles behind the Agile Manifesto

The business has entrusted their reputation in the Product Manager to manage a product. However, the Product Manger is not usually the sole decision maker when it comes to what to do with the product and when. Below is an insight passed on by Jeff Patton during his talk, “Top Ten Myths of Myths & Misconceptions of Product Ownership“.

Myth 1. You’re the decision maker for what product to build and when.
Reality: You generally lack authority to make decisions; you’re only the decision maker if everyone agrees with your decision.

The best Product Owners [Managers] make decisions based on a synthesis of suggestions and ideas from SME’s, Customers and Users, Business Stakeholders (CEO, Boards, Marketing, Finance, Sales), and the development team.

You’re the glue that holds SME’s, Customers and Users, Business Stakeholders, and development team together
You’re the lubricant that keeps things moving
Basically you stick and slide at the same time

(from my notes of the talk)

The product manager is not alone and gets input from business leaders, product leaders, and management. What sometimes gets forgotten is the development team. The product manager, business leaders, product leaders, and management all have a vested interest in getting the development team on-board with business strategies and goals. The development team, along with of the product manager, are the people who know the product best. The development team is not simply a partner in the business but a full-fledged member of the business team and should be recognized as such. And because the development team is made up of multiple disciplines, the advantages of this relationship is getting a diverse and unique perspective that developers, testers, BA’s and UXD people have of the product and of the customer problems to be solved.

Business decision and policy makers can choose to use or ignore any information obtained from any team member. It’s the difference between Authoritarian Decision-Making and Democratic Decision-Making; the Authoritarian makes the decision and doesn’t ask or care for the opinion of others while the Democratic Decision-Maker gets thoughts and ideas from others but still makes the final decision based on a diversity of ideas and opinions. The product manager can make the most learned decisions when provided with wide view-point of ideas and opinions.

Some points a product manager can experiment with while bringing development team members into the business decision process.

  • Builds business cases with product team, development team, marketing, sales, support, and management to achieve business goals through new product development or marketing.
  • Collaborates with one or more development team member to complete the business plan/Lean Canvas.
  • Collaborates with one or more development team member to gather technical feedback and suggestions for feature road map items and UX concept designs.
  • Provide shared vision and understanding of business attributes of road map items to one or more development team member

“and developers must work together daily”

So while the Product Owner [Manager] is held responsible for the product backlog, he or she must work collaboratively with many others to get the best product to the customers and users. A product manager works with business leaders and other business experts but also utilizes the “developers” to help. Now this is a two way street. Our manager above who asked if developers were to become product owners is not being an obstructionist but is likely supporting a business stance that roles are roles and one does not step across the abyss. Although a very traditional idea, it’s not an idea that will make collaboration and cooperation flourish in the organization. Some additional product manager role insights from Jeff Patton.

Myth 4. You work alone
Reality: Usability is generally determined through Users, UX people, and BA’s; Technically Feasible is generally determined through architects and Engineers; Business Value is generally what the Product Owner brings through conversations with customers and stakeholders.

All these people make up what is called the product team.

Most successful organization define a Product Team. Some dysfunctions of the Product Owner:
  – Don’t socialize decisions;
  – Don’t spend enough time with the team;
  – Don’t spend enough time with the customers

and

Myth 5. You create the backlog alone
Reality: Product Owner works with the product and their most important skill is leadership. Good leaders collaborate & motivates everyone; builds whole team ownership.

Product Owners give clear guidance and engage others to build & prioritize the backlog.
Product Owner not a good name; Product Manager not a good name. The role is not singular in scope or conduct.

(from my notes of the talk)

In organizations I’ve been in, the best behavior for getting the best product to customers was a result of product management and development teams working closely together. This would go beyond collaboration and reach the point where product and development shared an equal desire to deliver value to the customers in order to achieve a business goal. Of course both the product manager and development team bring their unique skill sets into play to reach a symbiosis of sorts. This kind of relationship doesn’t happen overnight and probably won’t be a painless journey, but success can happen. In one role, I was entirely unsuccessful in uniting product and development in this way but even in my failure, the two worked together in harmony, they just didn’t feel the same level of responsibility for defining the value through user stories. Of course, writing user stories is not the point, satisfying the customer is but over the years, I’ve noted development teams usually start from a technical place and need nurture to move beyond this mindset. There’s always room for improvement.

Another challenge is having the product manager to ask for or seek help from the development team, with creating the defining the business case for the product and creating/maintaining the product backlog. Consider for a moment a product manager who can’t let go of the idea that they and they alone create and build a product backlog. This most often is about trust and can manifested itself in the depth of detail of user stories written by the product manager, something that almost certainly guarantees resentment from the development team.  The breakdown in my view begins with the product manager and the development team not equally engaging with the customers and users from the start. The product managers did most of this alone without development. One way to ease the burden of writing stories is to begin introducing development team members into customer interviews, user testing sessions, and user observation sessions.

Another point of concern the product manager might have is a fear the development person might say the wrong thing in front of a customer. This is common fear and one that is not often substantiated with facts. In my view but can easily be overcome by getting the product manager and development team members to agree on behavior. Stress that the developer be allowed in the room during the interview but only for listening and note taking, at least in the beginning. This by far is the easiest way forward as the product manager and development team can build trust. It won’t be long before the product manager asks the development team member if they have any questions for the customer. Another big advantage to this is the development team member’s perspective on what the customer says. In the debrief after an interview, the development team member and product manager will probably find they interpret the same thing differently, which brings a richness to the interview missing if the product manager did it alone.

Getting the development team engaged with business cases and creating user stories isn’t often too a big issue but they generally don’t put up too much of a fight if the product manager insisted on doing it themselves. What important is that work isn’t done in total isolation with results passed from product manager to development team. This is type of hand-off is a key intersection of miscommunication. Results should instead be the result of collaboration and communication. This level of collaboration and communication needs to happen throughout the project, beginning to end, to reach the highest potential.

Some points the development team can experiment with to broaden their business and customer insights.

  • Provide technical feedback on feature road map items and UX concept designs.
  • Support (help create) and provide feedback on Business Plan/Lean Canvas.
  • Create and support User Stories to achieve business goals through new products or product improvements.
  • Provide estimates for the software components of road map items.Provide software estimates for user stories.
  • One or more development team member fully understands the business attributes of a road map item.
  • One or more development team member fully understands the customer pains and how solving these contributes to the business goals.
  • Development team actively participates in product backlog grooming sessions.

 

Agile Product Backlog Refinement (Grooming)

Feature image by Photo by Crystalline Radical.

 

In my last post, Agile Product Backlog Grooming Reduces Risk, I talked about using Product Backlog Grooming sessions as a project risk mitigation tool. In this post, we’ll further explore the details of backlog grooming with some tips to increase the value of grooming. These tips are for the Product Manager, Product Owner, and Development team to help make the grooming experience valuable and easy.

Development and Product teams begin the process of collaboration before the Product Manager has pitched the new/modified product idea to the business or before anything is actually in the product backlog. At this stage, most if not all information is based on previous experiences and assumptions. However, depending on your business structure, the Product Manager will probably validate most Problem & Solution assumptions prior to presenting the project to the business. The Development person here is the product architect or designated representative of the team(s) familiar with the product.

  1. Product Manager gets an idea (from any source) on how to achieve business goals with his or her product
  2. Product Owner and Development discuss feasibility of the idea, reworking the idea until thought feasible, based on the limited knowledge at hand.
  3. Product Manager/Owner develops business rational including the risks based on limited knowledge.
  4. Product Owner and Development collaborate to create the Business Canvas. You might consider using Ash Maurya’s Lean Canvas or Roman Pichler’s Product Canvas and Vision Board.
  5. Product Owner and Development collaborate to validate the Customer Problem and Solutions with customers through interviews and user testing. (Remove any Canvas entries that failed validation. Might need to go back to step 1.)
  6. Product Owner and Development provide an initial estimate. We’re looking for the ballpark, order of magnitude type estimate here e.g., 6 weeks or 6 months?
  7. Present Business rational and Canvas to business stakeholders for approval and funding.

Establishing preliminary understanding

The Product Manager’s product feature idea is now on the product roadmap (or equivalent). Depending on your business’s average lead time for work all the following steps could occur over the course of months or in rapid succession. My own experiences had roadmap items identified up to a year before the project, not very timely for customers but there are other factors at play including priorities, competition, and ‘hunches’ from the executive team.

These few steps are for illustration purposes and may not be what your team wants or even needs so feel free to modify for your specific needs. These steps will probably be done once. However, depending on the timing, may need to be revisited if the Product Owner and Development architect determine the data gathered has gone stale.

  1. Create one epic in Jira for one idea or feature. Most people use a tool rather than a big wall these days but if you have the wall space and an enthusiastic Scrum Master, by all means use a wall to define the high level projects.
  2. Development architects do initial technical scoping and high level design or impact mapping on current architecture. Unless you’re contemplating a new product, this will be based on the product’s current technical foundations and platforms.
  3. Full development team discusses the problem and possible solutions (non-technical). This is with a larger group of people using validated feedback from customers about how they envisioned their problem being removed from the user perspective. This serves as the baseline for UX designs. The discussion stays at the ‘what’ level but the full team might have something to say about feasibility and sizing.
  4. Full team provides updated estimates for Product Owner.
  5. Create the paper or wireframe UX designs & validate with customers.
  6. Development team (developers, UXD, and testers) along with Product Owner to define or confirm their collective understanding of what a ‘sprint ready user story’ is i.e. they define the Definition of Ready.
  7. Full team provides an updated estimate for the Product Owner.

The value to the business achieved during the above steps is to develop a good high-level understanding of all the work necessary for the initial epic user story. The team does a couple of estimates so the Product Owner can determine if the feature is still economically feasible. You’ll note customer involvement, looking at display mockups. The ideal situation is the customer finds that only a portion of the proposed work is necessary. The Product Owner and Development team keep focus on satisfying the customer in order to achieve a business goal.

On-going backlog grooming

This section details the steps for mainstream backlog grooming that gets repeated until a story is actually in a sprint. Most of these steps will be familiar. The full development team is ideally one Agile Scrum team but if there are several teams working a product, the grooming session should include those teams likely to work the stories. With a large number of teams (> 3), the LeSS framework, by Craig Larman & Bas Vodde,  suggests doing the grooming sessions in stages:

  • Overall Product Backlog Refinement (shared among all teams)
  • Team-level Product Backlog Refinement
  • Multi-team Product Backlog Refinement

 

  1. Full development team, using UX and architectural designs, begins breakdown of Epics into smaller stories using the Definition of Ready (DoR) guide the team established in the previous section.
  2. Product Owner and Development team continue to prioritize stories based on customer/business value but taking into account any implementation concerns or risks.
  3. Each user story is reviewed starting with those at the top of the backlog. Every user story is accompanied by notes, acceptance criteria, and estimates using the DOR as guide. If the story can be associated with a step in the ‘customer journey’, that would be a great help for stakeholders toward understanding the work.
  4. Product Owner and Development team review & discuss each story including those that are marked ‘sprint ready’. For stories not ‘sprint ready’, discussions on how the story could be implemented, could be tested, the customer value, and discuss compromises as necessary. ‘Sprint ready’ stories are checked that nothing has change that could affect the team’s understanding of the story or its priority.
  5. Again prioritize stories based on costs and customer / business value
  6. Check that all Epics and UX designs are covered with stories and have been prioritized.
  7. Make stories sprint ready and keep anyone who’s interested informed. My experience is most managers will not be looking through tools on a daily basis to determine progress. But being transparent is critical and using a big wall in a conspicuous location will provide the necessary details to management. If you have a ‘story wall’, you can use colored stickers to indicate status of stories i.e. sprint ready.
  8. The last step of every grooming session will be to again review the estimates and priority of the stories. Always check  the most valuable work is top-most on the product backlog.

The desired outcome of these sessions is:

  1. Big stories are split
  2. Stories are estimated
  3. Stories are well understood by the team(s) likely to implement them
  4. Stories are made ‘sprint ready’ based on the team’s Definition of Ready

Summary

In my experience, the amount of time needed between roadmap item to having a couple sprints worth of ‘sprint ready user stories’ is about 4 weeks calendar time, assuming development teams are busy doing sprint work as their primary activity. This provides time for any proto-typing, UX design, additional customer/user interviews, and getting input on marketing, sales, support, or other business concerns that could affect implementation choices. This could take a few days if done by an experienced project team in a full-time workshop.