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 Grooming Reduces Risk

Agile product backlog grooming is a development team and product manager/owner activity that removes the necessity of massive up-front planning. Backlog grooming is also a key risk reduction activity for an Agile project. The risks reduced or eliminated can include feature dependencies, costs, schedule, building the wrong product, knowledge, feasibility, and capability.

With Waterfall projects, there’s a great deal of up-front analysis of requirements and locking down scope from which cost and schedule are derived. There’s no need to ‘groom’ these requirements throughout the project because they’re not meant to change. Product backlog grooming is a frequently occurring process in Agile projects for the simple reason that Agile projects do not do full up-front requirements analysis. With Agile, the assumption is we focus on the value delivered to the customer and anticipate the customer changing requirements as their business world changes and evolves. Agile caters to the dynamic customer and business while Waterfall works really well for customers whose world changes very slowly if at all during the lifetime of a project.

In anticipation that some of the up-front analysis of requirements will be wrong, the Waterfall project manager puts in a great deal of effort to define and manage the risks associated with locking down scope so early, often times before people in the project know what they’re getting themselves into. This is a good thing because no one can know everything up-front.

Backlog grooming

With Agile, there is no pretense that we know everything. In fact, the Agile project team goes into the project knowing that they know very little of the details. For example, a typical Agile project might know enough to plan for the next 2-3 sprints (6-weeks if doing two-week sprints). Scrum defines an activity call ‘Product Backlog Refinement’, grooming by any other name, which is an ongoing process conducted by the Scrum team to add details, review, refine, estimate, and order the user stories in the backlog. While the Waterfall project has a risk registry and an ongoing risk management plan, Scrum involves the Scrum team in backlog grooming as a key risk reduction activity. These risks include:

  • feature dependencies – Scrum teams will try to make stories independent but this is a goal, not the reality. Implementation dependencies will exist at times and through the efforts of backlog grooming, these dependencies are identified. Once identified, the development team and product manager can order the backlog taking these dependencies into account
    costs – grooming can reduce wasteful work being prioritized too high. The scrum team combs through the backlog looking to keep those stories customers are willing to pay the most for near the top. Grooming keeps those stories that make achieving business goals and customer goals at the top while placing stories about, lets say, place settings on the titanic, at the bottom or removed entirely.
  • schedule – most projects work to some schedule and grooming helps keep focus on those stories that will make your project a success. Schedules might be tied to sales cycles, business cycles, customer deadlines, or events. The goals for these scheduled dates are usually agreed to by the teams but based on the available knowledge when the commitment was made. Backlog grooming can help keep the biggest bang stories, those stories that provide the greatest contribution toward the goal, at the top even as more knowledge is gained.
  • building the wrong product – backlog grooming asks if the stories in the backlog are what the customer needs so business goals can be achieved. As the project progress so does the likelihood that customer wants and needs change. Backlog grooming sessions check the staleness of information used to prioritize stories. If it’s been awhile since the team spoke with customers or customers have been absent from sprint reviews, then an action from a grooming session could be to re-validate a customer problem or solution with customers.
  • knowledge – product backlogs usually have the structure where large stories sit near the bottom and progressively smaller stories populate the backlog until the top 2-3 sprints worth of stories are small, ‘sprint ready’ stories. The process of taking larger stories and breaking these down to sprint sized stories never ends and will transcend projects. The process of breaking down stories involves digging out more details. These details can reveal a knowledge gap exists that needs to be closed before a story can be worked. Unless the story came up from the depths unexpectedly, there will always be time to recognize the knowledge gaps and find the knowledge either through training or getting a temp specialist.
  • feasibility – like the knowledge risk, feasibility can be handled before actual time to implement the story. When following a routine groom paradigm where large stories are broken down over time, it will be easier for the development team to provide earlier analysis of feasibility. The first analysis of feasibility would normally occur during the ideation phase, when a feature is added to the road map. However, the difference between “we should be able to do this” and “we know we can do this” can potentially put a company out of business.
  • capability – this ties in closely with the knowledge risk but is broader than team skills and capabilities. This includes things like test environment, development environment, build environment, customer access, and stakeholder involvement. Again, as larger stories are broken down during grooming, the team assesses the these needs to make implementation and delivery of the story successful.

Things that impede grooming sessions

Development team doesn’t feel responsible for the user stories.

“writing and rewriting user stories ain’t my job.”

I think this will be the impediment most often seen slowing down grooming sessions. I found that once development got used to their traditional roles, it was hard to get the developers on board with writing and rewriting user stories. Although the product owner remains accountable for the order of the backlog, they are not necessarily solely responsible for the stories.

All I can advise is setting the expectation that as members of the Scrum team, they all equally share the responsibility for the product backlog and its contents. This is best if re-enforced by management. The other factor will be time, it may take several months for the full team to accept this new responsibility. The Scrum Master can use the retrospectives as a vehicle for improving the grooming sessions. For example, can the bigger stories be broken down by anyone else other than the product manager? Someone in the team will suggest they can help the product manager. This is a very positive step forward. A note of caution: developers might try writing user stories that are very technical in nature.

Product manager not giving up control of user stories

I found that this will happen but goes away rather quickly as it’s the development team that needs good stories so they can attain a good understanding of the work required. This follows these three steps:

  1. Product manager controlling all aspects of user story writing
  2. Development team is in a struggle with the product manager over meaning and acceptance of user stories
  3. Product manager makes a business decision to allow the development team in on writing stories and reducing the amount of time explaining what the stories mean.

Backlog grooming sessions not a team event 

How much fun is backlog grooming for your Scrum team? Are you part of a team or scrum master of a team that goes to grooming only to agree with whatever the senior developer or team lead says? “Does everyone agree?” “Yes.” [Audible ‘TICK’] Maybe is was better when we did waterfall!?

It’s important that the first backlog grooming sessions be well facilitated so the team can be drawn in to the backlog and backlog grooming process. Going around and asking each individual what their opinion is, to explain their understanding of the story, and to describe what the high level design is will help. Some people will take to this quickly while others will take several grooming sessions to draw them out. Don’t give up but continue the facilitation until participation becomes natural for the team.

I’ve also seen where having the team lead or team manager as part of the team can stifle participation at grooming sessions. Providing coaching to the manager to encourage a ‘servant leadership’ approach is of inestimable value to creating a self-organizing team. This has worked great in the past and was the subject of a talk I gave at Scrum Australia 2016.

Being Agile When The Business Isn’t – Transparency

In the last two posts, ‘Being Agile When The Business Isn’t – Requirements‘, and ‘Being Agile When The Business Isn’t – Team‘, I talked about how to be more Agile in an environment where the business is strictly Waterfall. I’d like to continue this theme with some ideas and practices to make the teams more ‘transparent’.

Inspect, Adapt, & Transparency

Most will recognize Inspect, Adapt, & Transparency as the three pillars of Scrum but they’re ideas that even the most Waterfall of businesses can use and take advantage of. These three pillars are the core to continuous improvement, building what customers need to solve their problems, and helping bring the greatest valued work to the forefront. I’ll focus on transparency as I believe once you have transparency, inspection and adaptation will follow naturally.

Perhaps the big difference between Agile Vs traditional project management is how these three items are acted upon. When I was doing big Waterfall projects our alleged transparency came from the project’s communication plan. This communication plan defined the reports the project team was responsible for generating. At or near the end of the project, we wrote project closure reports which often included lessons learned. While writing the closure report, we were being formally transparent but only after everything was done. The real problem with the closure report was the timeliness of it. Because this is traditionally done at the end of the project, nothing learned here can help the just completed project. We also suffered from fading memories. We remembered the specific events but often needed to speculate and debate over the causes. Interestingly, we also seemed to forget these lessons for the next project or determine the next project is different enough so the lessons weren’t considered applicable. I’m not suggesting nothing was learned but any learnings carried forward tended to be the exception.

The result is some learning is done but the changes haven’t been trialed or proven to be effective in solving whatever the problem was. To improve requires openness and transparency so you can inspect what has happened and adapt to new and better ways throughout the project not just at the end. To maximize the value of improving, the project team needs to be continuously inspecting outcomes and results including any new ways of doing things. Building in transparency from the start will help.

Transparency

Transparency is arguably the first step for improvement. Nothing will help a business improve better than seeing undeniable evidence that some work practices, processes, and communications are less than optimal or just plain bad. In the Waterfall environment, the project plan includes what practices and processes the teams will use and the order they’ll use them. Most project plans also have a communication section where and how the various project statuses and metrics are reported. However, it’s only an illusion that transparency exists by executing a communications plan. The reason is, communication plans dictate specific content and intervals, usually within categorizes like any of the following:

  • Current project status
  • Current risk assessment
  • Resourcing status
  • Requirements management status
  • Stakeholder management status
  • Change management status

This doesn’t provide any insights or linkages to bigger or widespread problems. There’s also the problem that the reporting is done by the project manager. This can lead to information being filtered and potentially skewed due to conflict of interest. Project managers are generally held accountable for the project plan which means they’re accountable for perceived progress or the perceived lack  of progress. And finally, after a while, the project manager is most often simple ticking the box on his or her reporting requirements.

Daily standup & transparency

Scrum Trainer Charles Bradley wrote in his article, “The Tao of Scrum – Transparency“, “the best transparency leads to the best collaboration loops”. To maximize the value of collaborative feedback loops requires transparency and to me, transparency implies anyone can quickly gauge what’s happening in a project with a minimum of effort. Although you might be stuck with an old-fashioned communication plan, there’s an easy ceremony you can implement with your Waterfall team that gives extra clarity to what’s happening on the project: a daily standup. Each day the team talks about how their plans for the previous 24 hours went and what their plans are for the next 24 hours. It also provides an opportunity for others with their own unique perspectives to make observations and comment.

In my Waterfall past, as the project was approaching the final stages of test, we had all the project managers, line managers, and the program office people sit together daily to talk about specific tasks the teams were doing and when we thought they’d be done. Although this worked quite well for the management team, the nuance of individual planning was lost. Had there been a team standup, the confidence or uncertainty was more likely to come through. As it was, what was reported to management was an interpretation of plans and status.

In a Waterfall environment, the full project team might be large since the team is built from specialist who usually don’t take on tasks outside their specialty. This can mean the daily standup is large if everyone goes so careful monitoring is essential. The daily standup must remain valuable and true planning must occur otherwise there’s no point to it. In Agile, one valuable component of the daily standup is the collaborative nature of getting the most important work done first. In Waterfall, the project manager and product manager might need to be a little flexible in their detailed project plans to allow the collaborative nature of the implementation team to emerge. Better still is for the project plan be aligned with getting functionality done in order of importance rather than based on components and skills of the team.

Plans & transparency

Another aspect of transparency will be the visibility of the plans. If the project is using MS Project or Jira for Agile teams, it is a huge mistake to think this by itself constitutes transparency. Both these tools track progress when properly maintained but in both cases, people often don’t take the extra steps necessary to open a file or log on to Jira or even learn how to use the tool. The real problem isn’t progress wasn’t tracked, it is, but the real problem is the difficulty of getting to this tracking data and properly interpreting it. These tools have their advantages but ease of use is not always one of them. It’s not that these managers and program office people are lazy but rather their time’s at a premium. Visualizing the project and sprint status on a wall is easy. Bits of sticky paper with notes, in columns is easy. I have used a big wall as a Gantt chart or User Story board to great success. It really doesn’t matter if you’re doing Waterfall or Agile, the advantages of this high visibility is the same: huge.

If your team and stakeholders are global then it’s a wise idea to set up a camera on the planning board. I had used a camera while we did standups to allow global stakeholders to see & hear what was going on. I had a second camera on our ‘story board’ 24/7. This was intended to add more transparency and to give our global stakeholders a bigger slice of the picture, allowing for more feedback and collaboration.

Transparency is a conscious effort

Agile isn’t immune to poor transparency and communications. As Scrum Master, I’ve been cornered by the product owner/manager and asked what the ‘real’ state of progress was in the sprint. Two things needed to happen: the product owner needed to attend the daily standup and the team (with some advice from the Scrum Master) needed to better present state sprint progress. In Waterfall, the project manager has their hands full too. While Agile implies the implementation team is involved and responsible for managing expectations and communicating value completed, Waterfall usually relies on the project manager to do these. It’s up to the project manager to move beyond the project plan and establish a collaborative atmosphere where visibility and transparency become natural within the project team.

Transparency can be scary as it will expose people, their work practices, and their outcomes to all. It’s not the natural state for developers who learned their craft in a Waterfall environment. The first time I had transformed a Waterfall team into a Scrum team, one of the team members told me that they were completely stressed out by the high visibility of their work. In his case, a technical decision had proved wrong in a most open sort of way. In the past, management would probably not know that a technical glitch had happened but Agile made it visible. In hindsight, the team member realized the focus was to identify and correct a technical decision quickly and not to allocate blame or ridicule, (he was unconvinced of this in the first days). Transparency became a tool to do better and improve but not without some pain on the journey. Making previously hidden work habits visible will be stressful for some but this can be countered by avoiding the culture of blame and ridicule.

Summary

By using transparency as an aid to see what’s working well and what can be improved, the opportunities for improvement are more likely to be seen. Transparency has two key accomplices: daily standups and the wall project planner. Both these can be used in Waterfall environments without too much effort beyond simply doing it. Having the implementation team being transparent and talking directly to their plans each day is a key element of Inspection & Adaptation. This daily transparency reduces the risk of going off on a tangent as illustrated in the earlier story about an unsuccessful technical decision.

Transparency also extends beyond traditional tracking tools. Although these tools help track and document progress, it requires both effort and training to use these to their full potential. Training all stakeholders and customers with these tools is hard and may be impractical. Using a simple system of sticky notes and a big wall can convey the same information in a visual way that transcends most communication roadblocks. If there’s no wall, then use a big whiteboard. No whiteboard, then use the windows. You can even put a camera in front to broadcast the planning board across the internet if necessary.