Are your Product Owners Truly Empowered? Part 3

In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of knowledge that a Product Owner’s effectiveness is measured on. We looked at how various aspects of empathy influence a Product Owner’s ability to connect with the team, client and organization in our second post. In our third and final post in this series, we are going to look at the impact that psychological safety has on a Product Owner’s success.

Psychological Safety: Psychological safety is a state of mind and a cultural aspect that is created and fostered by someone or something other than the subject themselves. When people in the organization are afraid to make difficult choices and shy away from having tough conversations, it is generally due to a lack of psychological safety. Various factors contribute to how safe people feel psychologically in an organization. Empathy, as discussed above, at all levels plays a big role in this. If the culture, in general, is more empathetic, there will be a higher level of psychological safety. However, it is not the only factor. Let’s dig a little deeper on this factor and see how PO’s success is tied to psychological safety for themselves and the teams they are working with.

Psychological Safety for Teams: In the case of teams, it is usually the leaders that are responsible for ensuring that team members feel psychologically safe to work in challenging situations with often unpredictable outcomes. Agile requires teams to be flexible and collaborative in their approach to address the ‘just-in-time’ nature of work. Innovation, exploration, and taking risks is a necessity to succeed in such an environment. This comes with the possibility of teams running into occasional failures that should be treated as learning opportunities. But, if the organizational culture is not forgiving of failures, it leads to teams not feeling safe enough to take the risks and challenges they may need to, to optimize value delivery. Leaders should actively address the topic of psychological safety and ensure that they foster a culture that encourages innovation and taking calculated risks.
Psychological Safety for the Product Owner: The Product Owner is in a unique position having a tremendous influence on a team’s psychological safety, but in turn, are equally or proportionally affected by the psychological safety afforded to them by their leadership. A Product Owner who is well engaged with the team will need to make decisions regarding priority, scope, and timelines. An empowered Product Owner will be able to make such decisions with appropriate communication, keeping the team working at a sustainable pace. However, we often see organizations where such pivots must go through multiple levels of approvals, often surrounded by process constraints and red tape. This causes the organization to see change as undesirable and anyone bringing the change is viewed as the bearer of bad news.

Having leadership that welcomes change, is key to providing psychological safety to the Product Owner and the team. It is not sufficient for leadership to merely say that they support and welcome change. They need to look at systemic and cultural aspects of the organization that might be working against this mindset and actively work to realign them to an Agile way of working. It may not be the norm in some organizations to have leadership unsupportive of change, but a delay in the ability to pivot can lead to periods of unsustainable workload on the team while the Product Owner is negotiating upwards. To truly support psychological safety, allowing for making difficult choices and having tough conversations, organizations need to embrace decentralization decision making and empower the Product Owner and teams as much as possible.

Conclusion:
I hope you enjoyed this series. Throughout these three posts, we explored various factors that impact the ability of a Product Owner to work effectively in their role and serve the purpose they are meant to. They must be empowered with knowledge of not just the business domain, but also the delivery and process knowledge to successfully operate in the organizational context. Empathy at different levels of the organization and towards the customer, whether they are internal or external, is crucial to move the product in the right direction. Psychological safety is often an unmeasurable and underlying factor that should be proactively managed by leadership and ingrained in the culture and processes of the organization to truly empower their Product Owners.

As a final thought, if you’ve enjoyed this series or have additional questions on how to truly empower your Product Owners, join me for a FREE webinar on Product Owner Empowerment. We have a few seats available (on a first-come basis) and invite you to register today.

In the first installment of our Product Owner Empowerment series, we talked about the three crucial dimensions of ‘Knowledge’ that affect a Product Owner’s effectiveness. This post is going to take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed.

Empathy: Assuming positive intent, empathy is something that comes naturally to a person. However, environmental factors can influence a person’s ability to relate or connect with another person or team. Let’s explore some aspects of empathy and how they may impact a Product Owner’s success.

Empathy towards the team(s): To facilitate an empathetic relationship between a Product Owner and the team, the PO must be able to meet the team where they are (literally and figuratively). Getting to know the team members and building a rapport requires the Product Owner to extensively interact with the team and proactively work to build such relationships. Organizations should facilitate this by making sure Product Owners are physically located where the team is and is empowered to not only represent the team to the business but also play the role of protector from external interruptions, so that team can function effectively. As alluded to above, having a good understanding of what it takes to deliver, helps tremendously with the ability to place themselves in the team’s shoes and see things from their perspective.
Empathy towards the customer(s): It is easy to assume that a Product Owner acting on behalf of the business will automatically have empathy and an understanding of their needs to adequately represent their business interests. However, organizational culture can sometimes influence how a Product Owner prioritizes work. If it is only the sponsors directing the team’s scope and prioritization, a critical element of customer input is missed. Product Owners should place sufficient emphasis on obtaining customer opinion and feedback to inform the direction of product development.
Empathy in the Organization: This factor relates to the organizational culture. As companies embrace Agile and expect its benefits to be equally realized, more emphasis on the desire to be lean begins to form. While being lean is a goal every organization should have, it is important to understand what kind of impact a lean organization has on individual teams or team members. A systemic push to be lean, in combination with less than optimal Agile maturity and the presence of antipatterns, can lead to teams being held against unsustainable delivery expectations. This problem is more common than you would think. Most organizations are going through some level of Agile transformation, but leadership expectations of benefits realization are always a few steps ahead of where the organization truly is on the Agile journey. Having the right set of expectations and the empathy necessary to reset them based on continuous learning and feedback is needed at an organizational level.

Check back next week to see how a Product Owner’s success is tied to psychological safety for themselves and the teams they are working with.

If you are a Product Owner or your Agile team struggles with this role, you won’t want to miss our upcoming webinar on Product Owner Empowerment. This webinar will be held on December 15th and you can register today here! Space is limited and on a first-come basis.

The Product Owner plays a crucial role in the success of a team and subsequently the organization. Most organizations consider the Product Owner to be a person with sufficient business knowledge such that they can communicate the business needs to the teams for implementation. While this is an important qualifier for a Product Owner, other factors must be present to have a truly empowered Product Owner.

The following 3 factors have the biggest impact on a Product Owner’s ability to succeed:

Knowledge
Empathy
Psychological Safety

These factors are not just applicable to the Product Owner, but also the surrounding environment. This includes the organization, processes, culture, teams, the product itself, stakeholders, and customers. Let us dig a little deeper.

In this post, we are going to focus on the first influencer: Knowledge. Next week, we’ll take a deeper dive into the impact Empathy has on a Product Owner’s ability to succeed, and we’ll round out the series with defining Psychological Safety and looking at the effect it has on a Product Owner.

Knowledge: The knowledge aspect is the most obvious and widely analyzed and assessed factor to evaluate the effectiveness of a Product Owner. However, there are several dimensions of knowledge that are required.

Domain Knowledge: This dimension doesn’t need explaining and is probably the most obvious one of all. The Product Owner must have a good understanding of the domain they are working in, to effectively lead product development. While it may seem comfortable to assume that industry-wide it is common practice to have Product Owners with sufficient domain knowledge, some Agile antipatterns have led to the emergence of roles such as proxy Product Owner, or technical Product Owner. The primary culprit for organizations gravitating to this antipattern is a lack of understanding of the Product Owner’s role. Organizations assume that as long as there is a communication path to transfer the business needs to the teams, it is ok to have layers between the customer and the team. This creates dysfunction in Agile teams that are supposed to collaborate with the Product Owner in discovering and delivering value, but don’t have an empowered Product Owner who can make decisions and pivot when needed effectively.
Process Knowledge: When it comes to a PO having knowledge and understanding of the Agile approach, best practices, and antipatterns usually takes a back seat. To clarify, we are not talking about just having your PO take a 2-day certification class and call it a day. Yes, it is necessary to have formal learning as part of role development, but, the learning should not remain at this minimal level. An effective Product Owner should have lived the process, learned from the challenges, successes, and failures, so they understand what it takes to deliver the product they are helping build
Knowledge of PO role across in the organization: We talked about knowledge that a PO should have, but, to have a truly empowered Product Owner, an organization needs to know what to do with such a role. As mentioned before, a Product Owner role is different from a mere subject matter expert. To empower a Product Owner to make decisions, the organizational stakeholders need to understand how the Product Owner role works in an Agile context. Product Owners are not only the primary source of information on business needs for the team but are also one of the key roles influencing the pace of value delivery.

If the organization doesn’t understand what it takes for an Agile team to receive business needs Just-in-Time, iterate on requirements, let design emerge, deliver value and allow for slack time and innovation, It will make a Product Owner’s job quite difficult if they are still held to traditional expectations from leadership. These expectations may include providing inflexible delivery commitments, obtaining buy-in from a myriad of stakeholders before any scope changes are made, or worst of all, ensuring maximized utilization from the team. The organization’s stakeholders must be trained and knowledgeable about the basics of Agile if they are new to this way of working. Additionally, leadership must know the common pitfalls, assumptions, and antipatterns that organizations fall into and actively work to avoid or mitigate them.

If you are a Product Owner or your Agile team struggles with this role, join me for a free webinar on Product Owner Empowerment. This webinar will be held on December 12th and you can register here! Space is limited and on a first-come basis.

Why user stories don’t always make sense:

I am doing a lot of work with business units adopting Scrum or Kanban. As I explain to them, writing a user story in the correct format may not add any value to them. User Stories date back to Extreme Programming (XP). In the first part of the story “as a _____”, the blank is filled in with the user. As Product Owners identify users, they should be creating Personas that identify key user attributes. A millennial user will have different usage of an application than a retiree. These personas help the developer think about the user as they design how they will implement each user story. When a business unit is simply trying to get transparency about the work they are doing, their stories may be more of the “spike” or “technical” story variation. My question to these teams is can you identify the person receiving value when implementing the story? They think about this and sometimes think it is just their manager, or the company. The most common mistake is that the person doing the work is writing the story with their job title in the first blank; or getting a story with “As a Product Owner”. When using Scrum or any other Agile method for non-software work, I believe going through the effort of writing the story in User Story format As a ______, I want _______, So that______, just adds extra overhead, and no true value to the person doing the work. Instead, I recommend they save themselves that overhead and simply write “Create ____” or “Do _____”. The real value is in having good Acceptance Criteria. For example, if I want to have use a backlog for chores at home a User Story might look like:

As a Parent
I want the dishes done
So that the kitchen will be clean

Acceptance Criteria:
1 – No dishes remain lying around the house
2 – All dishes are in the dishwasher
3 – All kitchen surfaces are clean

Well this is great, I could just as easily write “Do the dishes” as my story keeping the acceptance criteria, so it is clear what is required.

For me, working in an Agile manner means reducing waste while increasing value. If you aren’t creating an application with users, going the distance to write a complete User Story is just waste. In Scrum there are four things in your product backlog, take advantage of that mindset. Skip the formality of the User Story.

Being a Product Owner is a really hard job. I have been hearing this for a long time and it has come out in almost all of the retrospectives in one way or the other over the years. Here are a few recurring themes I hear:

Product Owners and decision – making
I often hear things like – “My Product Owner doesn’t make decisions quickly enough or by themselves. It feels like they have to check with their leaders even before making even the most trivial decisions.”

My questions or thoughts revolve around – is it really a person thing, or is it pointing to the management not providing Product Owner the authority to do so? Is it the management’s mandate for the Product Owner to seek approvals before making any decisions?

If that’s the case then not getting the questions answered in timely manner can impact the completion of work and eventually has a significant impact on Time to Market. It is probably how the organization is structured and the organization probably needs to shift from a Do Agile to a Be Agile mode.

Product Owner is not technical
When did the requirement to be a Product Owner become technical? A Product Owner doesn’t need to be technical. They need to answer the team’s what’s not really the how’s.

Going back to the Agile Principles: The best architectures, requirements, and designs emerge from self-organizing teams.

Product Owners should not be the ones providing teams the technical direction. They should be able to provide the vision to the teams.

Teams are the ones who make the technical decisions around the design and architecture. The entire team and the Product Owner can look into the various design options and discuss the trade-offs but it is the team that is responsible for the how the implementation will take place and how long would it take.

Product Owner is not available to make the decisions
Being a Product Owner is a full time job. A Product Owner should have ample time to sustainably carry out their responsibilities. If the individual is overworked, the team’s progress suffers and the resulting product may be suboptimal.

At a workshop this week many of the Product Owner attendees were overwhelmed with the length and breadth of the Product Owner role. They said things like, “As a Product Owner should I be making all the decisions?”, and “Are they really a single- wringable Neck…..but why??”

This role is by no means is an easy role. They have to be constantly engaged in conversations with the stakeholders, keeping a check on the pulse of the market, looking at trends and innovation but at the same time be available with the team to answer all the questions.

I feel very strongly about the Product Owner making the decisions – at a team level the Product Owner is expected to make the decisions. They are responsible for providing the answers to the team. Be the single point of query or decision making body for the team. The Product Owners should be available to the team at least for some dedicated team time or core hours every day.

You should be that leader for the team so the Team does not have to look any further. The Team can just ask questions of you and get an answer and be sure what is required off them to fulfill the commitment that they made during the sprint planning or the PI planning.

But in all honesty is it Team Vs Product Owner….not really
The memories of best teams that I carry in my heart are the ones in which all of us worked together. We were open enough to call out ‘hey, need you for this and that,” or “I need …….this from you,” and “you need to show up for this meeting and be available at this time…”.

The team (onsite and distributed), Scrum Master and Product Owner all were available during core hours and would address things as they came. Does the level/seniority of Product Owner in the organization matter in the quality of decisions they make? Or is it how much confidence and trust their team and leadership places on them?

Before we start to worry if we have the best Product Owner in the whole world, or if we can be the best Product Owner, it’s important to remember that Product Owners, like the rest of the team, need time and support to acquire the necessary skills.

Everyone has their unique strengths and weaknesses and that’s what we bring to the team. A Product Owner might be great at providing the vision for the product, interacting with the team and stakeholders, but may not be the best at writing user stories. In areas of inexperience or weakness, the team would pitch in, helping with the work and enabling Product Owner growth.

So, ultimately what matters is the ‘We’ as in team not ‘I’ as a Product Owner.

As described by Jeff Sutherland, the Product Owner (PO) is “the person responsible for managing the Product Backlog so as to maximize the value of the project. The Product Owner is responsible for representing the interests of everyone with a stake in the project.”

The Product Owner is a key role in the Scrum framework. It’s a tough role, and people often have difficulty embracing it. Today, I’ll discuss some of the common questions we get from POs in the government arena.

What’s my Role?
A Product Owner maximizes ROI by:

Identifying product features
Prioritizing features and other work
Ensuring a steady flow of value by choosing the most important work for the next sprint
Continually re-prioritizing, elaborating, and refining the list

A Product Owner guides and supports the team, keeping them from thrashing, by:

Continually painting a picture of the destination (the vision and context)
Ensuring a steady flow by “feeding” the team ready work
Being available and actively interacting with the team on a daily basis to answer questions and provide guidance
Making decisions to keep the team moving forward
Providing a link between business stakeholders and the team
Providing feedback as a sprint progresses
Signing off on work results
Providing a single voice to the team on product priorities and decisions

A Product Owner represents stakeholder interests by:

Actively interacting with stakeholders to identify needs, gather information, and solicit feedback
Ensuring the product creates value for stakeholders

What Skills do I need?
A Product Owner has, or develops, deep knowledge and competence in:

Business domain and subject matter expertise (SME)
Understanding and empathy with the customer, business, and market
Weighing risks and making timely decisions with available information
Conveying vision, setting context, and contributing to team and stakeholder understanding by “telling the story” of needs, behaviors, and success criteria
Understanding and incorporating appropriate techniques to communicate with the team and stakeholders
Understanding and use of conflict resolution techniques
Understanding of group dynamics and complex change
Negotiating priority and trade-off decisions
Facilitating discussions and decisions
Sensing and scanning inward, understanding and providing what the team needs to be effective
Challenging the team to improve
Sensing and scanning outward, understanding and delivering what stakeholders want/need
Managing stakeholder expectations

What’s my Title?
“That which we call a rose, by any other name would smell as sweet” – Shakespeare

Scrum does not specify who should play the Product Owner role. It only provides a general description of the role and responsibilities, and identifies a framework of ceremonies and artifacts that guide what to do.

So, the PO can be anybody (e.g., a Business Analyst, a Product Manager, or a Program Manager commonly play the PO role), as long as they have the necessary skills and time to dedicate to the role. How they fulfill the responsibilities of the role will vary from person-to-person based on experience, need, and organization culture, structure, and constraints.

For smaller projects/product lines, with fewer teams, the PO responsibilities can be handled by one person (e.g., a product manager, senior business analyst, or program manager).

In larger organizations, or larger programs/product lines, the PO responsibilities are often divided because one person won’t necessarily have the skills or sufficient time to fulfill the needs of the role.

A common division occurs at the intersection of the “inward”, team-facing, tactical responsibilities (handled by a business analyst) and the “outward”, customer-facing, strategic responsibilities (handled by a Product Manager or Program Manager). It’s important to remember that even if there is a division of labor and responsibilities, there will likely be some overlap and constant collaboration and “mind-melding” is required. This maximizes transparency, minimizes hand-offs, and ensures congruent decision-making. From the team’s point of view, there is still one PO, a “single voice” providing priority, information, and decisions.

Why is the PO role so hard to grasp?
Product Owner is a role, not a title. A “job role” is a function that’s performed, a description of the part a person plays. A “job title” is the name given to a position within a company, one that typically implies stature or hierarchy.

Traditional job titles have evolved over the years to align with specialized skills, collapsing roles, responsibilities, and skills into common titles (e.g., business analyst, project manager, and tester). These tried-and-true titles have a long history, and are recognized, hired, measured, compensated, and rewarded similarly across the industry. Many of us define ourselves by our job titles; they represent status and stability, identity and importance, achievement and acceptance.

Then along comes the Product Owner. A new role with skills and responsibilities that not only don’t map cleanly to a job title we’re familiar with, but actually overlap several (e.g., product manager, program manager, project manager, business analyst). Our axis shifts, our identity is challenged, and we sometimes find ourselves adrift in ambiguity. To compensate, we grasp for a detailed description and firm boundaries to help provide clarity.

This is a common “shu” response when acquiring new knowledge, especially true when that knowledge comes with a significant shift from what we’re used to. As we learn and become more comfortable, the need for boundaries lessens and our tolerance for ambiguity increases. Mentoring and coaching can help support individuals through this uncertainty.

How is a government PO different?
The Product Owner role itself is not really any different in the government….the responsibilities are essentially the same, as are the skills required.

What makes the government setting unique is the combination and degree of:

organization structure
funding strategies and acquisition constraints
compliance requirements
technical complexity
requirements complexity

I’ll talk briefly about how organization structure affects the PO role; the other factors are outside the scope of this blog.

Although the size and approach to government IT programs/projects is changing, at present they still tend to be on the large side. The number of different agencies and/or vendors involved, the number of teams, and where work is performed are all factors in determining complexity of the program structure.

It’s typical for government agencies to rely heavily on vendors to “design-build-test” their solutions, and keep the requirements definition and user acceptance (UAT) in-house. Subject matter expertise is split between government staff, who primarily have business domain knowledge and expertise, and vendor staff, who primarily have technical domain knowledge and expertise.

Since a key skill set for the PO is deep business domain expertise, it makes sense then for the PO to be from the government staff. And since the PO is responsible for making scope, schedule, and budget trade-off decisions, the ideal candidate would again be from the government staff. The government program manager is often a good choice as the PO, but care should be taken to adequately consider who is best positioned to handle challenges such as those identified below.

Typical, traditional government practices transfer risk and responsibility for failure to the vendor, but having the PO from the government staff means responsibility for successful delivery shifts to the government, as they can no longer claim to not be in the know.

PO Challenges in a Government setting
There are a number of common challenges that can impact establishing strong and effective Product Ownership of government projects and products. The considerations listed here are not all unique to a government environment, but often occur at a higher rate.

Key considerations include:

Time commitment – being a PO is a full-time commitment, not something that can be done “off the side of the desk”. Most of the considerations listed here affect the time commitment required by a PO. Environments where all of these factors occur will significantly impact a PO’s productivity and effectiveness.
Distance – remote teams increase a PO’s workload. This increase is often not considered when determining PO/team ratios. There are tools that can help, but it just takes more time and effort to establish a rapport and communicate with teams and stakeholders who are physically remote from the PO.
Hierarchical structures – power dynamics and hierarchical lines of authority can hamper a PO’s ability to make timely decisions.
Frequently changing vendor teams – increase a PO’s workload, requiring more support to build intellectual knowledge and onboard teams.
Multiple projects/products – one PO, one backlog, one team is a rule of thumb. That will vary somewhat depending on their maturity, the team’s maturity, and the type of work being done.
Customer availability – PO’s need timely access to end-users and other customers/stakeholders to be effective. Generally, the less customer availability, the more PO time is required for coordination.
Supportive environment – PO’s need support from leaders and sponsors to reinforce decision authority and help remove organization impediments.
Acquisition constraints – PO’s in the government are sometimes also the COR (Contracting Officer Representatives). Their SME knowledge makes them a good choice for this, but increases their workload, especially during pre-award activities.
Governance/Compliance – heavy compliance usually means a PO spends less time on CVA (customer value add) activities, and more time on BVA (business value add) activities.

So there you have it….leave a comment, I’d love to hear your thoughts!

I once read a book, which shall remain nameless, that seemed to have a quota of illustrations per page: an average of one-third of each page covered by an illustration. It was a horrible read, made all the worse when I realized that the figures were often repeated to illustrate different concepts with only the captions changed.

Happily, although Ron Jeffries’ own illustrations manage to cover perhaps an average of a fifth of each page in his new book, The Nature of Software Development, they actually add value rather than just taking up space. Take the illustrations that Ron uses to introduce the idea of incremental software delivery. It’s very easy to see how people envision their final product in terms of the magic they believe it will be.

The very next illustration, though, helps us recast our thinking in terms of incremental delivery and how it helps us start deriving value from the product we’re building and then another illustration shows how we can use the feedback we get from the earlier releases to produce something better than we’d originally imagined. Most of the time I honestly ignore illustrations and diagrams as useless, but Ron’s illustrations are generally thought provoking and I always found myself stopping to think about how they illuminated the text around them.

The first part of Nature covers “The Circle of Value,” understanding what value is, why we should try to deliver value incrementally and how we can build our product incrementally. The second part of Nature is entitled simply “Notes and Essays” and provides more detailed thoughts on some of the subjects touched on in the first part. One of my favorites was “Creating Teams That Thrive” where Ron reminds us that when the Product Champion, the term Ron is now favoring over Product Owner, brings defined solutions to the team they are less likely to feel a sense of responsibility and pride in the result.

Another nice essay was “Whip the Ponies Harder,” where Ron reminds us that trying to pressure a team into delivering faster can have deleterious effects. But this brings up a point I wanted to make about the book itself rather than what it says: If you’ve followed along with what Ron has been thinking over the years, in the various discussion groups in which he participates, on xprogramming.com/ronjeffries.com or at the various presentations and classes he’s done, there may not be anything new for you in Nature. Even if you’re in that situation, it’s probably worth getting the book anyway. There’s always the possibility that there will be new thoughts for you there, and, even if the ideas themselves aren’t new to you, their presentation in Nature can spur (sorry, the horse/unicorn drawings may be doing something to my language) you to think about them more deeply and also give you a new way to explain those ideas to other people.

A final word of warning: Early on Ron says “[Y]our job is to think a lot, while I write very little.” This reminded of the time when someone told me they’d read XP Explained (the first edition) in a weekend and understood it all. After fifteen years, I’m still deepening my understanding of XP, mostly through trying to introduce its values to development groups that don’t necessarily understand what, if any, values they hold. Even though it’s a short book, give yourself time to really think about what is said in Nature, even after you’ve finished reading it. That’s when the most reward will come.

What Details?
On a recent flight, I was reading about paying attention to detail in creating a dream room for your home. Attention to detail is important whether you are decorating your house, or building software. I work with Product Owners trying to write user stories so often, I instantly thought “I need to write about user story details”.

When teams are getting started with user stories, the inevitable question is where do my detailed requirements go? I think this is especially true when I work with huge organizations in highly regulated industries.

Details are Important
I’ve seen Product Owners (especially those that were formerly BA’s) fill entire user story description areas with details. In Agile practices, that flies in the face of what the user story is meant to convey. User stories are a trigger for a conversation. User stories should convey to the developer what the user wants to do and why. Once we get past the basics of the user story, then and only then, can we add details in the form of Acceptance Criteria and other attachments (wireframes, mock-ups, database excerpts, etc).

Before I go into user stories, I want to say that not all product backlog items (PBI’s) are user stories. PBI’s may be defects, technical stories, or spikes. If you are a feature team working on a web development project, then demand good user stories. However, if you aren’t in development, or the PBI isn’t a user story, then I question whether or not there is value in trying to force folks into the user story format (As a who, I want what, So that why). I do not question, ever, that we must provide detail along with conversation in order for the work to be performed, tested and accepted.

In organizations that have component teams working on ETL (Extract Translate Load) functionality, middle tier software services being written separately from the consuming team, or scrum teams not related to software at all (marketing, sales, audit), Agile still works and stories still make good PBI’s. Just don’t force yourself into the “user story” format if it doesn’t add value.

Check out Mike Cohn’s blog here for more on “back-end” stories http://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems

Sometimes we use the Agile Manifesto as a reason for skimping on what is needed. I fully believe in “Working Software over Comprehensive Documentation”. I am the first to ask, “who is going to read all this”. However, I also ensure that my teams get everything they need in order to provide quality results. If this means the Product Owner must work harder at getting the stories ready, then that is what they do. It is their job. Organizations need to know what a big job the Product Owner has. Just because we move from a waterfall version of requirements to Agile versions of requirements doesn’t mean the job takes half the time. In fact, it may take longer. Product Owners must break down stories, get details and be present for discussions with the rest of the team during story grooming/refinement sessions, or during development. If a developer wants more details the Product Owner must get them.

Creating User Stories
What does the process look like? To go from the initial creation of the title to a fully ready story can take any number of days. How much time and effort is spent on documenting the story depends on where it is in the stack ranked order of the backlog. I would rather not put all my effort into stories that aren’t coming up in the next 2 – 3 sprints. Even though I have hundreds of titles ready to go for months’ worth of stories.

Let’s take a look at some examples
The following user story could be broken down smaller, for a start though it meets the basic user story criteria telling who, what and why, but not how. It includes acceptance criteria, and if we were in a tool, I would expect to see supporting attachments.

Title: View Order Details
Description:
As an online customer
I want to see a summary of my complete order before I hit enter or submit
So that I feel confident everything is correct
Acceptance Criteria:

Ability to preview the order is available
Preview includes shipping address, billing address, item list, shipping costs, tax, total , payment info (see wireframe attached)
Payment info shows only the last four digits of card used

User stories are a trigger for a conversation. As we have the conversation a lot of questions should be asked… and results of those questions can be noted below the acceptance criteria.

Now let’s look at a technical story for a component team not invited to share in the front-end team’s user stories:

Title: ETL Sales Report – Team GoGo
Description:
Data must be loaded into the sales data warehouse in order to provide metric reports
Acceptance Criteria:

Data from XYZ database, tables 1, 2, 3 loaded into warehouse ABC table XXX
(see attached schemas)
Stored procedures scheduled to run nightly to load data
Data transformations run without error
On error message “….” Sent to “….”

Here is a non-IT story:
Title: 2015 Security Audit – User Access Process System X
Description:
Audit Onboarding process with HR to ensure User Access requests follow approved processes
Acceptance Criteria:

Audit covers 80% of all request in last 12 months
Manager’s interviewed and results documented (name, position, date)
Document audit results following Procedure 123
Auditor should not be able to request User Access without following the process

So where are the details?
In the Acceptance Criteria and associated documents! If something is missing, get it there before accepting the story into a sprint. If the story looks too big, break it into smaller pieces. Ensure you cover happy path and not so happy path options. Plaster your cube with domain models, object models, etc.

As I mentioned in the introductory post in this series, an issue I frequently see with underperforming Agile teams is that work always spills over from one iteration into the next. Nothing ever seems to finish, and the project feels like a waterfall project that’s adopted a few Agile ceremonies. Without completed tasks at iteration planning meetings (IPMs), there’s nothing to demo, and the feedback loop that’s absolutely fundamental to any Agile methodology is interrupted. Rather than actual product feedback, IPMs become status meetings.

In this post, let’s look at how a Product Owner can help ensure that tasks can be completed within an iteration. As a developer myself, I’m focusing on the things that make life easier for the development team. Of course, there’s a lot more to being a good Product Owner, and I encourage you to consider taking a Scrum Product Owner training class (CC Pace offers an excellent one).

First and foremost, be willing to compromise and prioritize. An anti-pattern I observe on some underperforming teams is a Product Owner who’s asked to prioritize stories and replies, “Everything is important. I need everything.” I advise such teams that when you ask for all or nothing, you will never get all; you will always get nothing. So don’t ask for “all or nothing”, which is what a Product Owner is saying when they say everything has a high priority.

As a Product Owner, understand two serious implications of saying that every task has a high priority.

You are saying that everything has an equal priority. In other words, to the developer team, saying that everything has a high priority is indistinguishable from saying that everything has medium or indeed low priority. The point of priority isn’t to motivate or scare the developers, it’s to allow them to choose between tasks when time is pressing. You’re basically leaving the choice up to the developer team, which is probably not what you had in mind.
You’re really delegating your job to the developer team, and that isn’t fair. You’re the Product Owner for a reason: the ultimate success of the product depends on you, and you need to make some hard choices to ensure success. You know which bits of the system have the most business value. The developers signed on to deliver functionality, not to make decisions about business value. That’s your responsibility, and it’s one of the most important responsibilities on the entire team.

The consequence of “everything has a high priority” is that the developers have no way to break epic stories down into smaller stories that fit within an iteration. Everything ends up as an epic, and the developer team tends to focus on one epic after another, attempting to deliver complete epics before moving on to the next. It’s almost certain that no epic can be completed in one 2-week iteration, and so work keeps on spilling over to the next iteration and the next and the next.

Second, work with the developer team to find out how much of each story can be delivered in an iteration. Keep in mind that “delivered” means that you should be able to observe and participate in a demo of the story at the end of the iteration. Not a “prototype”, but working software that you can observe. Encourage the developers to suggest reduced functionality that would allow the story to fit in an iteration. For example, how about dealing only with “happy path” scenarios – no errors, no exceptions? Deal with those edge cases in a later iteration. At all costs, move towards a scenario where fully functional (that is, actually working) software is favored over fully featured software. Show the team that you’re willing to work with the evolutionary and incremental approach that Agile demands.

Third, be wary of stories that are all about technical infrastructure rather than business value. Sure, the development team very often need to attend to purely technical issues, but ask how each such story adds business value. You are entitled to a response that convinces you of the business need to spend time on the infrastructure stories.

At the end of a successful IPM, you as the Product Owner should have:

Seen some working software – remember, fully functional but perhaps not fully featured
Offered the developer team your feedback on what you saw
Worked with the developer team to have another set of stories, each of which is deliverable within one iteration
Prioritized those stories into High, Medium, and Low buckets, with the mutual understanding that nobody will work on a medium story if there are high stories remaining, and nobody will work on low stories if there are medium stories remaining
A clear understanding of why any technical infrastructure stories are required, and what business problem will be addressed by such stories

Finally, make yourself available for quick decisions during the iteration. No plan survives its first encounter with reality. There will always be questions and problems the developers need to talk to you about. Be available to talk to them, face to face, or with an interactive medium like instant messaging or video chat. Be prepared to make decisions…

Developer: “Sorry, I know we said we could get this story done this iteration, but blahblah happened and…”

You: “OK, how much can you get done?”

Developer: “We would have to leave out the blahblah.”

You: “Fine, go ahead.” (Or, “No, I need that, what else can we defer?”)

Be decisive.

Next post, I’ll talk about what developers should concentrate on to make sure some functionality is delivered in each iteration.

Scrum purists will tell you co-located teams are the way to go. If only it was that easy!

As large organizations adopt scrum, they find themselves struggling with how to be more Agile when many of their teams are distributed. As coaches and trainers, it is our responsibility to support this reality.

There are many blogs and articles like this one on the web that talk about working with remote teams.

Many of the articles I see offer common sense tips like:

Make the most of tools for instant messaging, video conferencing, and shared content.
For ceremonies, use video conferencing whenever possible.
Ensure Team Agreements, Definition of Done, and Definition of Ready are in a shared location.
Team Agreements need to include core hours when everyone will be on instant messaging.

Here are some of my own more unique suggestions:

Dealing with time zone differences – Although ceremonies should be at the same time/place whenever possible, consider alternating times by month, or sprint. For example, on odd months favor east coast times, while in even months favor west coast times. Don’t do too small of an increment (like daily).
Time for a celebration – Ensure everyone on the team, regardless of location, goes out and celebrates. Schedule an extra 15 minutes post scrum to discuss what everyone did. Get creative….hold virtual “coffee breaks” or “pot lucks”; celebrate personal events (such as birthdays, births, leaving, etc) as well as team accomplishments.
Tracking Sprint Progress – Utilize your tools’ dashboard during daily scrums to show the teams burn-down. Don’t micro-manage tasks. Insist team members keep tasks up-to-date reducing ETC to keep burn-downs current.
Product Owner – As a Product Owner (PO), engage fully with the team to ensure collaboration leads to comprehensive understanding of each story. Ask questions. Update stories in real-time during team grooming to clarify understanding. It is easy to leave PO acceptance of stories until it is too late for developers to make changes. Instead keep an eye on story progression, review stories as soon as they are ‘done’.
ScrumMaster as team facilitator – As a Scrum Master (SM), your role is especially important with distributed teams. Pay attention to how members interact. Is everyone participating in ceremonies like grooming and planning? Ask questions to draw out quiet members. Also, just because you are the facilitator, doesn’t mean you have to “be in charge”. Don’t forget to turn items like tasking stories over to developers. Just sit back and listen while they do the work. Consider a SM for each location (e.g., if you have part of the team together on the east coast and another part together on the west coast, use a SM in both places).

There’s no doubt about it…..it’s harder for remote teams to achieve the same collaborative environment that co-located teams can. But it’s not impossible….with a little elbow grease and TLC, your distributed team will shine!”

The role of a Product Owner in Scrum includes owning the backlog and preparing stories for sprints. As I work with product owners I remind them that not every item in the product backlog needs to be ready to develop.

Agile backlog and user story progression reminds me of the pyramids.

When we first start, we are at the base of the pyramid. Our customers have such big ideas we call them features. When we start to think more about the feature ideas, we create epics further defining what our customers will want. Those epic stories are still too big to fit into a sprint. So we continue to break them down into small pieces called stories.

As the stories get closer to being taken into a sprint, the story must be small and refined. A good Definition of Ready (DOR) will help us understand when stories are ready to move from the Product Backlog to the Sprint Backlog. The DOR helps the team agree on what must be included with the story in order for the dev/test folks to do their jobs. The basic story and acceptance criteria are required parts of the DOR. In addition, the team will add various items to the DOR list, e.g. wireframes, examples of formulas, and database excerpts. Product owners should be working on stories they would like to see be developed within the next 2 – 3 sprints.

So in my example here, as stories percolate to the top of the pyramid, product owners review them with the team in grooming sessions. Then at sprint planning, the top stories are pulled out of the product backlog and become the sprint backlog.

The saying “just enough, just in time” helps keep product owners focused on ensuring the right stories get to the top of the pyramid, just in time for the team to work on.

For more information, check out Mike Cohn on the topic:https://www.scrumalliance.org/community/articles/2008/february/writing-the-product-backlog-just-enough-and-just-i