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
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.
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
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
- 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
Data must be loaded into the sales data warehouse in order to provide metric reports
- 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
Audit Onboarding process with HR to ensure User Access requests follow approved processes
- 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?”)
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