An Idea in An Agile World

All new products and new product features start with an idea. This idea becomes the first user story, user story #1, for the product. User story #1 begins a journey that could end with either happy customers and happy business stakeholders or end up in the bucket of disused ideas. So what happens to user story #1 and what do you do with this new idea?

You can find lots of articles on breaking down user stories. You can also find articles on how to write good user stories but you usually don’t see too many articles on how the first user story is used to develop a business case. What follows are some thoughts and insights on how to take user story #1 and developing it for greater success.

User story #1

User story #1 is the idea. It’s an idea to achieve business goals, an idea to solve customer problems, and an idea to create or change a product. We’re all familiar with user stories written with an eye toward solving a customer problem through product updates. User story #1 is different as it’s not so much about solving a customer problem as it is a ‘thought’ experiment to discover what customer problems we can solve. So the question is, how should we go about validating the idea?

Validating

When the new product idea is first presented as a means to achieve a business goal, there will be interest but it’s unlikely the business is going to throw monies your way, at least not at first. The business needs more than just the idea, the business needs data to back-up and justify the idea. This translates to meaning the idea is put through the discipline of Ideation or Envisioning.

The idea is the highest level user story for the product but the picture is incomplete and outcomes uncertain. However, there’s usually enough to the idea to begin analysis and experimentation. The analysis often results in a series of metrics and measures collected during envisioning. These are often measured on a some scale that best serves your business. For example, aligning to company strategy might be scored 0=no alignment, to 5=full alignment. Costs might be 0=<$10,000 to 5=>$450,000. Below are some metrics you might be familiar with.

  • Alignment with the company’s strategy,
  • Moves the product team towards achieving a business goal,
  • Is technically feasible,
  • Product innovation category (new, adjacent, or sustaining),
  • Cost associated with it (implementation is usually the biggest component),
  • Predictable business outcome if implemented (revenue, customers, users, …),
  • The business risk of implementing/not implementing is calculated,
  • The competitive advantage, and
  • The market breadth (new, adjacent, or sustaining).

To do the above takes time and you might look at the list and think, “that doesn’t look too agile to me”. Today’s reality in the digital age is all these items need to be completed in the morning so the development teams can implement and deploy by late afternoon. For most of us this isn’t exactly true, yet. But time is a pressing consideration and being quick is important. What we need to find is a way to do business so we have both enough knowledge to start and we have a clear idea of what further information we’ll need. The key bit of knowledge we need to have up front is that the idea aligns with the business’s strategy and goals.

Big ideas need to align with business strategy & goals

Before the idea is broken down, or before any real effort is made, the idea should be validated against the business strategy and goals. You might be lucky and the business strategy is developed in such a way that the product manager can have their ideas incorporated into the strategy from the start. When the business defines what their goals are, they develop a strategy to achieve those goals.

The three elements of good strategy (source: Richard P. Rumelt, Good Strategy Bad Strategy)

  1. Diagnosis: “A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical.”
  2. Guiding Policy: “A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.”
  3. Coherent Actions: “A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.”

Working backwards on this list, new product ideas describe the actions needed to deal with the challenges (goals) found during the diagnostics. In this way, new product ideas become an integral part of the company’s overall strategy.

If the product manager can align their ideas with the business, then the remaining items of envisioning can happen relatively quickly. It’s very likely that for most ideas, the effort to define feasibility and cost can occur within an agile team’s iteration. This is a tremendous way to cut the time from idea to completing envisioning. It also provides for giving the customers a chance to evaluate the idea in a practical sense: A/B tests, user testing, or customer interviews. This technique of learning is often used in the Startup world as Build-Measure-Learn cycle.

The product manager will likely obtain full approval for any opportunity that delivers overwhelming value relative to its cost. Kenneth Rubin in his book, “Essential Scrum: A Practical Guide to the Most Popular Agile Process“, suggests that if there’s any discussion over tiny differences in cost or value then it clearly doesn’t deliver ‘overwhelming’ value and the idea should be dropped.

The easiest and best way to determine value is by getting the idea in front of your customers and users and measuring their response.

Using the development team for envisioning

When speed is essential to capitalize on an event or competitive opportunity, get something out in front of the users today rather than waiting until you’re sure. The trick will be to do only enough to answer questions and reduce risks without over committing the team or business. Keep in mind that you and the business haven’t validated the idea yet so there is a risk. If you’re doing Agile then this will fairly straight forward: use build-measure-learn techniques to understand the value of your idea with customers and users.

The product manager works with the product owner, team leads, architects, or full development team to break down user story #1 (the idea) into smaller user stories. These are the fragments needed to showcase the new product or feature idea. These particular stories are not necessarily work to build a product but will often be part of a prototype or demo system to gather information and feedback. Part of the envisioning process is to validate the idea, confirming its potential, with customers and users. To do this, a demo or prototype to showcase new features to potential customers and users can be an enormous asset without spending too much money in the process.

If the product manager has the luxury of dedicated team at their disposal that’s great! However, a new product idea may not as yet have a team but only a handful of senior people to help bring a new idea to life. Assuming there is a team, one approach is to get a team to include some research work along with their normal complement of product work. This is handled as spikes, technical or business exploration, added to the sprint if doing scrum. (If the agile teams are Kanban then there’s less of a concern with disruption and immediate priorities can take precedence.) If there’s a time critical component to the idea and waiting isn’t an option, then cancelling a sprint and pivoting to take on higher value work is an option but not always a good idea. Besides, if doing scrum there’s already a mechanism in place to do research, prototypes, and mock-ups: the backlog refinement sessions.

Using the development team during envisioning helps the product manager answer some important business questions including these 2 metrics from above:

  • technically feasibility-team can better answer this after developing a prototype,
  • implementation costs-implementation is usually the main influence on costs and the team can make a more accurate estimate.

By using the feedback and learnings from the demo and prototype, the product manager can better determine the viability of the idea. Using A/B tests, user testing, or customer interviews, the product manager can:

  • better estimate the business outcome if implemented (revenue, customers, users, …),
  • better assess the business risk of implementing/not implementing the idea,
  • better assess the effect on competition, and
  • better understand the market breadth.

Getting the development team involved with the idea early on will benefit the product manager. This early involvement moves the team from being a partner with the product management into being full members of the business team, bringing along their unique skills and insights into the envisioning process.

Two key outcomes having the development team in on envisioning

One big advantage is the development team is better positioned to undertake the new work if the business decides to proceed. The development team also has more ‘skin in the game’ through early involvement.

Another big advantage is the product manager can determine sooner whether to pursue the idea further. Because the development team has created prototypes or demos for customers, the product manager is better able to collect critical information for the business case. If it turns out there is no profitable business case, the product manager has spent relatively little money to learn a lot. The agile principle of maximizing the amount of work not done is an important one and finding out early to stop is better than running out the budget on a hunch that doesn’t pay off.

In a waterfall environment?

If you’re doing a waterfall type methodology then it’s a given that all envisioning and requirements are defined upfront. This is not bad if there’s little to no uncertainty. However, the early involvement by the full development team to pursue the idea using prototypes is still valid. They’ll not only be putting more ‘skin in the game’ but they’ll improve the accuracy of the estimates and potentially uncover more unknowns.

Summary

To increase your chances of success, get the development team involved during envisioning. They can help the business best if they’re a full member of the business team and not just a partner. Use the full development team to validate user story #1. This includes validating customer problems, potential solutions, development costs, and business value.

 

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.

 

Make Agile User Stories Personal With Personas

Feature image “Proto-Persona” by visual.ch (CC BY-SA 2.0)

When a product owner or product manager helps create user stories with the development team, does the development team walk away feeling empathy for the customer? Can the development team and business benefit if the team ‘feels’ for the customer? Most businesses are pushing their development teams to produce all the time, from project to project, so developers eventually get used to this pressure and find their own behavioral niche within the organization. So why would a team suddenly begin doing more work in less time than any project before?

At a previous company, we had the advantage of being able to know the names of our customers and potential customers. This didn’t always happen but when the development team knew a customer’s name it was magical. During the daily stand-ups, the development team talked about the next bit of work they’d tackle but they’d also talked about the customer, “Is that what Bill (not the real name) wants us to do?” Management also talked in terms of the customer when speaking to developers. The development team knew their stuff and were top developers but they looked at the work with an eye equally on their customer’s wants and needs. The team spoke the customer’s name so it was clear they knew exactly who they were working for. The team’s productivity shot way up and they even worked weekends to get the right product into “Bill’s” hands sooner. This was a dream team for the business and would be the envy of most companies doing Agile. Or Waterfall.

Now that’s a nice, feel good story about a development team’s awareness of their customer but this is probably the exception. E-commerce businesses flourish these days with thousand upon thousands of customers so it would be difficult if not impossible to get a development team rallying around a single customer. The next best thing is a persona representing a customer, a customer segment, or a user profile. I first learned about personas from Alan Cooper in his book, “The Inmates Are Running the Asylum”. At the time we might have missed the mark sometimes because our personas were very detailed in things that nowadays would be considered unnecessary and less helpful in aiding product decisions. However, personas can help development teams feel a closeness to their customers and be more empathetic towards their customer’s pain.

What I generally notice is companies have personas but they’re often used only in Marketing. The idea is to get these personas out to everyone involved in product development and steering the full product team’s thinking towards personas as real people. I was at a great presentation by Atlassian product manager Sherif Mansour who spoke at Agile Australia a couple of years ago on the topic, “Do Agile Right – Lessons Learned From an Atlassian Product Manager“. This easy to listen to video touches a bit on using personas and journey lines. Atlassian uses personas as the backbone of their product development. If you’d like more information on creating personas, see the end of this article.

User stories by Mike Cohn

Connextra is credited with the most popular user story format, “As a <blank> I want <blank> so that <blank>“. This is a simple yet elegant way to capture “who”, “What”, and “Why” for a software requirement. But it’s Mike Cohn and his book, “User Stories Applied“, that really made user stories come alive in the Agile community. Mike Cohn does suggest that the ‘why’ is optional but I think for teams early in their Agile journey, this will be very beneficial as it helps new Agile teams understand the customers’ problems better.

A good user story can provide an innovative and imaginative development team all the necessary information to begin their task of talking with stakeholders and the product manager in order to figure out how they’ll do the work. The goal of the user story is to provoke conversations to get more details rather than writing a specification.

So does this happen and if it does, how often? My experience shows this in fact rarely happens. Yes we write user stories using the format, “As a <blank> I want <blank> so that <blank>”, but we’re really following a cargo cult software engineering ritual without really understanding the purpose of the user story. This is exactly where personalizing the user story can reap great benefits.

Personas in user stories

A lot of user stories I see look like this:

“As a user I need to see an error count so I can track whether the number of errors exceeds my reporting threshold.”

This story was constructed for the “user”. Unfortunately “user” is such a general term doesn’t tell us who the story is for; is the story for an 8-year old or 80-year old grandmother? Is the story for men or women? It’s going to be hard for someone to read the story and be empathetic toward the “user”. There’s no human connection to this story so no one should expect much in the way of human feeling toward implementing the story. The development team is just as likely create a display item that shows a simple error count because that’s the easiest and fastest way but is it the best way or is it what the customer really wants? What’s missing is the personalizing of the story which can be expressed in the form of a persona. By personalizing the user story, the question the developer asks is, “is this what ‘Grandma’ wants?” instead of, “does this meet the acceptance criteria?”. If the whole product team, (finance, marketing, sales, support, development, and product management), are behind helping Grandma out, it’s just that much more likely to happen.

Personas and visibility

Now someone reading this is saying, “but we said who the user was at the grooming session” and that’s great but now you have a story that only a small handful of people knowing who the story is for. This shows a certain complacency within the agile team and not being transparent to the business. By avoiding tying the story to a specific business concern in the form of persona, other parts of the business are in the dark as to the real value provided to the business by delivering this story. How easy would it have been to put in persona “grandma” instead of “user”? The Product Owner and Development team owe the business this insight and should always be aware of what they’re communicating to the business. If the agile team is looking for autonomy and empowerment, what better way to earn this than by being open and showing they are striking at the heart of business concerns.

Summary

The real advantage of personas will come from the development team as they create solutions in quick and caring way. Even if the development team only increases value delivered by a couple of percentage points, the product manager, the business, and the customer win. This can happen if the development team’s interest, excitement and commitment can be inspired by using personas. Atlassian treats their personas as people and the company talks about their personas as real people. This is not too far from the experience I spoke of earlier in this piece where the team talked about their customer.

There are as many styles of personas as there are customers. If you link a user story to a specific persona and that persona maps to a business or customer segment, then it will be easy for the business leaders to quickly see the potential value the team is planning to deliver. It also gives the development team a chance to relate their work to the goals of customers represented by personas.

Learning more

I am assuming most people reading this are familiar with creating personas but for those less familiar, here’s a site to get you started with personas.  There’s also help from Roman Pichler who, in his article “From Personas to User Stories“, provides a template for developing personas. An example of Roman’s persona template is shown below. Roman suggests that personas and their goals begin their appearance in the larger, epic, user stories and flow all the way to sprint ready stories. This will help focus the team on solving problems for a semi-living customer and it will also make user testing easier because the goals of that customer are defined in the persona.