Author: Robert Galen

User Stories Ready, Set, GO!

Written by Robert Galen on August 20, 2013. Posted in Articles.

Introduction

Have you ever entered a Sprint taking on a User Story that you later regretted? For example:

One that you should have broken down a wee bit more?
Or one where the team had not a “snowball’s clue” how to technically implement?
Or one where the value wasn’t clear from a business perspective?
Or one where the estimate and the reality were not equal?
Or one that, when you got it “Done”, you weren’t quite sure how to determine that it was done?

I’m guessing, of course you have. I encounter these scenes in teams I’m coaching all the time. And truth be told, it’s not a terrible event. Teams make mistakes…all the time. And they usually learn from them.

The real problem, from my perspective, is with the teams that continue to do this sprint over sprint over sprint. Yes, the dynamics slightly change, but the end result is the same.

The team is taking on User Stories that are truly not READY for the Sprint!

So the question is: what can be done to prevent it? Is there a technique that will prevent this from happening or are these teams doomed to keep repeating their mistakes? I’m glad you asked.

The Flip Side of Definition-of-Done

I hope everyone is familiar with the terminology Definition-of-Done (DoD)or Done-Ness from an agile methods perspective. It’s a common phrase and incredibly important to agile team health and maturity. It’s essentially exit criteria, if you will, for the teams sprint work.

At a User Story level, it’s common to refer to each story’s acceptance criteria as the done-ness check for story completeness. At a sprint complete level, it’s common to refer to the Sprint Goal as the checkpoint for what the team was trying to deliver. And done-ness also permeates into how each team member does their work. For example, are code reviews part of a teams’ done-ness criteria? If so, then they will consistently plan for and execute code reviews as a part of developing and delivering each story.

So the Definition-of-Done is an “exit criteria”; one that determines condition of completeness for work being delivered. But there is another criterion that is useful in agile teams at the “other end” of the workflow—the delivery end. Let’s call it Definition of Ready (DoR) or “Readiness Criteria”. In this case, it’s associated with each individual work item that flows through an agile team.

If you’re practicing Scrum, then it would be at the Product Backlog Item (PBI) level. If you’re an XP team or leveraging User Stories, then it would be for each story that enters a team. The readiness criteria would be a clear definition of what connotes a User Story or PBI that is “ready” for execution within the iteration or Sprint.

It turns out that preventing ill-defined stories (or work) from entering each Sprint in the first place, is an incredibly healthy way of warding off the challenges I described in the introduction. But let’s explore readiness in a bit more detail.

Ways of Looking At It

The 4–R’s

Tony Shawver is a coach and consultant working for Matrix Resources in Atlanta. In this blog entry, he described a method or approach for defining “The 4-R’s” of story readiness:

Raw – This is an “initial placeholder” User Story which generally only includes the title and possibly a supporting sentence or two. It allows the Product Owner or stakeholder to enter the general thought for later refinement.
Refined – In this state, the Story has been refined by the Product Owner or stakeholder and includes: a) an appropriate title, b) an adequate description, and c) acceptance criteria.
Reviewed – In this state, the Story has been reviewed by one or more team members. The team members have vetted the general requirement and posed needed questions/clarifications back to the Product Owner/stakeholder for response.
Ready – The content of the Story is complete, all questions/clarifications have been made, and all acceptance criteria are adequate for development and testing. This Story is now ready to be taken into a Sprint planning (or pre-planning) session.

Stories and work on the teams Product Backlog is moved through these ‘phases’ as a way of preparing each story for execution. Clearly a story could move from Raw to Ready very quickly. Let’s say it was a small, relatively straight-forward story that was clearly understood by the team. A few questions and some writing later, the story should be “good enough” for execution. Conversely, a complex or technically challenging story might take many iterative discussions to move it into a Ready state.

Ultimately, the team is the final arbiter for whether a story is ready or not—based on their understanding and ability to envision executing the story without major impediments.

Roman Pichler

Roman Pichler wrote a book related to the Scrum Product Owner role. Since he and I are competitive authors, I try to quote him as infrequently as possible. But he shared a blog post that focuses on this topic and I thought it valuable to share. Here’s an excerpt:

A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artifacts are simply attached to the story, as the picture below illustrates…

Roman brings up a couple of important points in your definition of readiness:

Operational Constraints – define any and all constraints that the story will have related to releasing it. I like the notion of viewing agile work from “concept to cash”. I.e., it’s not ‘done’ until it’s in production and being used by your customers. So, from that perspective, make sure that all of these constraints are visible as part of the story.
Sufficient Pre-work Design – another important balancing act agile teams have is guarding against BDUF (Big Design Up Front), while still doing just enough design to fully understand the scope and integration of a feature. This is particularly important when a team is working on cross-team features or on technically complex work. You can see design being needed at a UX level, but also in general.

Thanks to Roman for helping to “flesh out” a healthy alternative view to readiness.

Another way of Describing Ready

I personally like a checklist approach for describing teams’ readiness criteria for work. Here’s an example of the sorts of checks that I’ve seen prove valuable for teams to leverage when maturing their stories:

The Story is well-written; and has a minimum of 5 Acceptance Tests defined.
The Story has been sized to fit the teams velocity & sprint length; for example somewhere between 1-13 points.
The team has vetted the Story in several grooming sessions—its scope & nature is well understood.
The team has the requisite skill-set & experience to implement the Story and deliver it to meet the organizational and teams’ Definition-of-Done.
If required, the Story had a research-spike to explore (and refine) it’s architecture and design implications; or to explore the testability challenges associated with it.
The Story describes end-to-end behavior in the system.
The team understands how to approach the testing of the Stories’ functional and non-functional aspects.
Any dependencies to other Stories and/or teams have been “connected” so that the Story is synchronized and deliverable as part of the “greater whole”.
The Story aligns with the Sprints’ Goal and is cleanly demonstrable.

So there are no distinct phases in this case. A new User Story simply has to meet all of the above checks in order for it to be considered ‘ready’ for execution. How each story gets ready is up to the Product Owner for each Product Backlog collaborating with their team. It could take one or fifty steps to get there. It could be fast or slow. But working together, they decide on how to shepherd a story towards execution readiness.

Beyond Scrum, you can see how this technique would be useful. If you’re implementing Kanban, than readiness criteria is the definition work required for something to enter the “ready queue” on your Kanban Board.

Relationship to Backlog Grooming

So you might be asking yourself the question, how does a User Story achieve done-ness? From my perspective, it’s part of ongoing, real-time Backlog Grooming or Backlog Maintenance that a team takes on as a natural part of maturing their Backlog.

Regular grooming meetings provides a venue for these discussions, and as a part of grooming, I like a 4-phased approach to reviewing stories. What Sprint each story is planned for delivery is a leading indicator for when it’s grooming needs to be completed by. I call each phase a “different point of view or lens” for looking at the Backlog and what’s moving towards execution & delivery. For example:

Lens One: The Very Next Sprint – These Stories would need to meet the readiness criteria. Using a 4-R’s approach, these are READY.
Lens Two: 2-3 Sprints in the Future – These Stories are quite mature. If they needed design work or spike work, it’s been done (or minimally planned). Using a 4-R’s approach, these are REFINED to REVIEWED.
Lens Three: The Next “Release” – These Stories our in the future. Typically, they’re far from ready, but the teams’ responsibility is to “get them ready”. Often early activity surrounds estimation and removing technical risk or ambiguity—so that the Product Owner can “plan for” and commit to the release. Using a 4-R’s approach, these are mostly being REFINED.
Lens Four: The Far Flung Future (Epics) – These Stories are future context based. They mostly help the team to understand where they “might be going” in their development efforts. High level sizing’s and ROI determination is a large part of the work here. Using a 4-R’s approach, these are mostly RAW to slightly REFINED.

I sometimes refer to grooming as a “conveyer belt” moving User Stories close and closer to execution. The concept of Definition-of-Readiness nicely complements this analogy and strategy.

Wrapping Up

I often use the term guardrails as a synonym for DoD. These are constraints that are defined for the team to help “keep them on the road” to agile maturity and delivery. I would liken the Defintion-of-Readiness (DoR) or readiness criteria as another guardrail for the team. These are not typically part of the “Core Scrum” definition. However, like User Stories and Backlog Grooming, they are incredibly useful practices for many teams.

If you go back to the introduction, those struggling teams have lost sight of how to properly pre-define their work. Establishing a Definition-of-Ready for a while should help them improve. Once that becomes a part of their culture and DNA, then it may not even be worth definition going forward, as it’s served its purpose.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

References

Tony Shawver’s blog post
Roman Pichler’s blog post
Agile Alliance definition
A few additional links to Definition of Ready information:

Moving Beyond “The Backlog” – The 4 Quadrants of Product Ownership, Part 2

Written by Robert Galen on July 2, 2013. Posted in Articles.

In part one of this two-part article, we explored the first two quadrants. Here we will complete the quadrants and wrap things up. First up is the notion that the Product Owner is also a “leader” within the team.

Quadrant 3: Leadership

All right you say…enough is enough! Product and project management are both fairly pervasive responsibilities. Now you suggest that a Product Owner has to “worry about” leadership as well?

Well, yes, that’s exactly what I’m saying. In fact, it may be the most important quadrant from an overall team perspective. The first leadership aspect relates to the products themselves. Product Owners have a responsibility to establish a vision for their work. Along with this is goal-setting. So many Scrum teams forget that Sprint Planning starts with a “Sprint Goal” that the Product Owner brings into the meeting.

Beyond goal setting, the Product Owner needs to provide individual leadership to their team. This implies a connection to the team, membership, and loyalty—something that the team ‘feels’ in every interaction.

Perhaps this story can help explain it…

Are you simply a “Business Savant”?

I was presenting an agile workshop not that long ago and I presented the group with this scenario:

One of your team members is pregnant and going on short-term maternity leave. She will be gone for 8 weeks and then return. In terms of your iterations, she’ll be gone for 4 sprints. She happens to be the strongest Database Architect and Engineer on your team. Yes, there are two other less experienced Database Engineers, but they both usually need Susan’s experience to help them along in their tasks. In fact one of those is a college intern, quite bright by the way, but inexperienced nonetheless.

It just so happens that your backlog is filled with Database-centric work at the moment; aligned towards some major features you wanted to get into the next release. Probably 75% of each sprint is heavily skewed in this way.

So here’s the million-dollar question, as the teams Product Owner, do you change the strategy and focus of the backlog based on this event? Or do you continue to drive current priority into the team and expect them to deliver as always? And these changes could be major or subtle; the question is: do you (or should you) change anything in your workflow because of this ‘event’?

I would contend that the answer is a resounding—Yes! That you shouldn’t be solely driven by blind value and priority, but that “situational awareness” is needed on the part of great Product Owners. This to me is an example of principled leadership and having the courage to adjust as required, while still keeping your eye on the overall project and business goals.

Change this example around to shift the Product Backlog flow to amplify your teams’ strengths and minimize their weaknesses.

Or to give them work that is interesting and challenging;
Or to be sensitize to the amount of technical challenge you give them on a sprint-x-sprint basis;
Or to consider the teams’ feedback when planning for defect repairs, refactoring or implementing automation;
Or to allow (better yet, foster) innovation on the part of the team towards solving the customer’s problems rather than simply implementing by-rote feature lists.

All of these reactions are fair game from my perspective in a Product Owners journey in translating business needs towards team implementation. Point being—there’s a balancing act that needs to be achieved and it’s not totally skewed towards the organization.

Communication & Defense

In my Scrum Product Ownership book, the sub-title is Driving Business Value from the Inside Out. What I meant by that sub-title was that the Product Owners primary responsibilities were toward the team. That only by caring for and feeding the team well, could they deliver on the quality, value, and productivity promises of the agile methods. That delivery of results was through the team.

To that end, part of the leadership responsibility is to be a primary communication mechanism for their team. Sure, the Scrum Master role has communication as a strong responsibility, but rarely does the Scrum Master get the opportunities for communication that the Product Owner receives. You’ll be interacting with senior leadership, stakeholders, and customers. Please take the time to communicate all aspects of your teams’ efforts and progress.

If someone questions an aspect of your teams’ efforts, come to their defense. Keeping in mind that you are also a member of the team; so they’re questioning your efforts as well. Remain fully transparent in communicating your backlogs, plans, and efforts.

Shared Leadership

A final word on your leadership role relates to the Scrum Master. In my coaching, I strongly encourage each team’s Scrum Master and Product Owner to establish a leadership partnership between them. A part of this is role overlap when it comes to leadership dynamics. But beyond that, I think agile teams need a modicum of leadership in order to inspire them to high performance. This partnership can help provide that balanced leadership.

Quadrant 4: Business Analysis

There’s an incredible amount of discussion in the traditional Business Analysis (BA) community about the role that BA’s should fill within agile teams. Some take the perspective that the role is exactly the same. That is, eliciting and defining upfront requirements and then handing them off to the team for implementation. I would disagree with this view.

Others take the position that the Business Analysis role continues, but it transforms quite a bit. That there are more partnerships required—partnerships with the team, with the testers, and most importantly with the customer or Product Owner. And that the role is not solely an upfront focused role, but rather continuously engaged throughout each release. That Business Analysts are, if you’re lucky enough to have them, a member of the Scrum team. I subscribe to this view.

If we circle back to the definition of a Product Owner being the owner of the Product Backlog, then the Business Analyst quadrant activities become quite clear. Ultimately the backlog is composed of Product Backlog Items, User Stories, or dare I say it, “requirements” for the team. To that end, these stories need to be well written and developed with the team. If the Product Owner has a BA background, then they are nicely suited to lead this work. But what if they don’t have that background? Then it becomes a whole-team activity and BA’s, who are incredibly skilled at writing requirements and specifications, bring a lot of value to the team here.

If you leverage the User Story format for your backlog items, then they are iteratively defined with the team. Not only do they contain a functional description, but they also contain “conditions of acceptance” from a business perspective. Here the Product Owner plays a part in communicating to the team the value proposition and nuance you’re looking for in each feature. It’s so important, that I want to explore it in a bit more detail next.

Acceptance Criteria or Tests

User Stories were invented or developed as a requirement artifact in the Extreme Programming space. The intention was to develop a low fidelity (3×5 card) construct that would be developed to ‘contain’ software features, requirements or work items. These would be low investment artifacts, from the perspective of writing, but they were intended to drive high collaboration and discussion.

Many teams focus on the “story part” of the User Story and don’t attend to the acceptance criteria. I personally feel these are incredibly powerful. First of all, they communicate the aspects of each story that the Product Owner and customer values, what are important or crucial system behaviors, and what are the critical checks that need to be made.

But beyond that, acceptance criteria provide incredible hints to the team. From a developer’s perspective, they communicate key design constraints. From a testing perspective, they communicate much towards the effective risk-based testing strategy for each story. They help the team balance effort to priority to value for each story. They drive questions, answers, and ongoing clarification.

Business Analysts are in a wonderful position to help iterate on story evolution as the team attacks their understanding of the work and its ultimate execution and delivery. Often they serve as a crisp communication and details liaison between the customer and the team.

Partner with Business Analysts

I often find that this quadrant is a challenge for most Product Owners. They have a tendency to be much more comfortable with Product Management and Leadership. Project Management is sometimes a challenge or stretch, but they typically ‘get’ most of the planning aspects of the backlog.

However, writing good agile requirements or User Stories can often be an intimidating chore. Here’s an excerpt from my book that illustrates that challenge…

I met a Product Owner not that long ago who was quite stressed out. He was relatively new to his company. While he had some agile experience, being immersed into a new agile environment, team and domain was quite intimidating.

I came into the organization as a coach and was just trying to get a sense for the environment. He quickly pulled me aside and confronted me with a problem. He complained that he simply didn’t have the time to construct stories, or a backlog for his team.

It turned out that he’d been working into the night for the past 2 weeks to get an initial backlog together. His team was “waiting for it” and it was taking him a long time to get the backlog completed. He was struggling with his domain experience and technical understanding of the products underlying architecture. He was also struggling with writing effective acceptance tests for the stories. Since he was new, he kept working on them; trying to create the “perfect backlog” before ‘presenting’ it to his team.

I can’t tell you how stressed out and exhausted he was.

I suspect my reaction might have seemed odd to him. I asked him to immediately stop working on the backlog stories. Instead, I asked him to schedule a story-writing workshop where he, and his team, would sit down and create the backlog TOGETHER. I told him to bring his current story mix into the meeting – as-is. It would serve as a nice starting point for the team.

I reminded him that the Product Owner shouldn’t ‘own’ writing all the stories; that the Product Owner role was more of a backlog facilitative role. I also reminded him to leverage the whole team in crafting a solid backlog and that he never had to “go it alone” in preparing a backlog.

I ran into him after the first workshop and he appeared incredibly relieved. He said the workshop was outstanding and he was amazed at the ability of his new team to rally around fleshing out his ideas. His renewed energy and enthusiasm were music to my ears.

And beyond the whole-team aspect of this story, imagine if you have Business Analysts available to you as a Product Owner. What a wonderful that partnership that would create as you guide a rich stream of well crafted stories towards your team.

Wrapping Up

I said in my book that Scrum Product Ownership is arguably the hardest job on an agile team, whether you’re operating as an XP customer, Scrum Product Owner, or other customer-centric role. While collaborating around the Product Backlog is a central part of the role, I think that view is way too narrow.

I hope the 4 Quadrants sensitize current and potential Product Owners and their organizations to the true depth and breadth required to do the role well. It also helps when staffing the role, planning training, and allocating others to support the Product Owners own skills in fully supporting all aspects of the quadrants.

Way too often I see organizations trivialize the role and overwhelm single Product Owners with all aspects of the role—independent of their skill and time. Now our focus should be across the quadrants towards “feeding the team well”.

Thanks for listening,
Bob.

Don’t forget to leave comments below.

[1] User Stories are refined within the team during a process called Backlog Grooming or Backlog Maintenance. The team will typically ‘see’ each story several times as it moves from a large-scale Epic or concept definition to an much more finely decomposed, understood, well estimated, and executable story in each sprint. I have a rule of thumb that a story should be groomed 3-4 times by a team as it moves towards execution and as the team decomposes and refines it. This is what I’m implying by “iteratively defined”.

[2] Scrum Product Ownership, 2’nd Edition

The Agile BA: Moving Beyond “The Backlog” – The 4 Quadrants of Product Ownership, Part 1

Written by Robert Galen on June 11, 2013. Posted in Articles.

When I say “Product Owner” to you – what do you think of? And when I say “Product Backlog” to you – what do you think of?

I ask these specific questions all of the time in my classes as a means of introducing basic agile topics and gaining a feel for the level of experience of the attendees. There’s usually a relationship between the two answers.

The common answer to the first question is: The Product Owner ‘owns’ the Backlog. So, what is the ‘Backlog’? The second answer is usually a list of attributes:

It’s a list of things to do
It’s ordered by priority or business value
It’s sized by the team
It has varying sizes of work items
Early items or more finely grained than later items

All of which are created by the Product Owner for the teams’ consumption and delivery—since the Product Owner…’owns’ the Backlog. Let’s extend the discussion a bit by sharing the current definition of the Product Owner role by Ken Schwaber and Jeff Sutherland in their Scrum Guide:

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Ensuring the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

This is what I mean by having a “the Backlog” view or mentality when it comes to Product Ownership. It’s far too simplistic and revolves almost totally around the backlog. And while that is indeed a large part of the role, it does the role a disservice by being far less nuanced than truly needed.

In my book on Product Ownership, I speak of 4 key areas that a Product Owner must focus on to perform well in the role. They include:

Product Management;
Project Management;
Leadership;
Business Analysis.

I like to characterize these areas as “quadrants” of the role and responsibilities that lead to effective and solid Product Ownership. In this 2-part article, I want to explore each quadrant in more detail—broadening and adding nuance to each, and therefore to the overall role.

Quadrant1: Product Management

The first quadrant of the role is one of classic Product Management. I’ll reference Pragmatic Marketing for help expand this quadrant. This is the outward-bound part of the Product Owner role, the one that dialogues with stakeholders and investors to sort through the vision and the roadmap for a product. They are the ones who run focus groups and interview real-world customers to determine their problems and challenges. Then they help create innovative product-driven potential solutions to those challenges and problems.

Another part of this quadrant is serving as a product champion. Quite often Product Owners are in the very best position to demonstrate the product. They understand the workflows at a high level and can quickly run through the critical functional scenarios. They’ve probably worked in the problem domain, understanding customer challenges, and are creatively trying to solve those problems.

Still another part of this quadrant is establishing a product mission and vision. Often they establish a release roadmap with key stakeholders by gathering everyone’s vision and then aggregating it into a cohesive whole. Quite often these roadmaps lead to release milestones and customer commitments, which need to be managed as each release of the product unfolds. This part of the quadrant connects quite nicely with the execution bits you’ll see in the next quadrant (Project Management) discussion.

There’s also a true Marketing aspect to the role—pulling together functional overviews and whitepapers that explain the product and help the sales team. This would also include other types of collateral, including pricing and ROI models, while preparing sales channels for a successful kick-off or release. So there is a strong connection from thus quadrant to the organizations sales and customer support functions.

Nowhere in this quadrant did I speak about the Agile or Scrum team. This quadrant is truly externally facing, either toward internal stakeholders or towards the outbound customer. One final point, if you have Product Managers as a role within your organization, it is often a full-time role within itself. That can create quite a disconnect when introducing the role of Agile Customer or Scrum Product Owner, in that now you’re adding more responsibility on top of a potentially overloaded role. Watch out for this when you’re deciding whom to select as your Product Owners.

Quadrant 2: Project Management

This is the quadrant that receives possibly the most pushback when I present it. Everyone has a picture in his or her head of a traditional software project manager and they simply don’t connect it to Scrum Product Ownership. So what does project management have to do with the role?

I’m glad you asked. I think a good place to start is by envisioning the Product Backlog not simply as a prioritized list of requirements, but something more. You see the backlog is the one artifact in agile teams that captures the features, the work, the flow, the risk, etc.; it’s essentially a Work Breakdown Structure or WBS for agile projects. Given this, I think a healthy backlog is a place for traditional project management activities, for example:

With the team, taking a “step back” from a sprint-by-sprint focus and looking for the most effective way to deliver on a releases’ goal(s).
Early on, aligning stakeholder expectations on content with each team’s capacity and confidence in delivering that content.
Establishing early architectural and design work that established a framework for supporting the content in the release. This is not BDUF, but LDUF .
Embedding testing activities and strategies in the backlog, particularly in high application integration or regulated environments.
Sprinkling milestones (rallying points, integration points, demonstration goals) throughout the backlog that show how the team will be building functionality up towards their release.
Ensuring that the team is considering all work that is required to take a customer-usable release from the concept phase and get it into the hands of customers for usage.

Release Planning

One of my early agile experiences was with Extreme Programming or XP. In our Meta-Cast the other day, Josh Anderson and I were discussing this quadrant and I mentioned this.

One of the activities associated with XP was something called Release Planning. It was tightly coupled to User Story writing and creating a work list or backlog of items to work on. Visually, figure 1 represents the process. When I was doing it in the early days we would simply use masking tape to tape iteration “swim lanes” on a long conference table. Usually our releases were on the order of 10-12 iterations, so we would have quite a few lanes spread across the table.

The next step was to distribute the work, user story cards, across each of the iterations. Usually the team would do this. First they would take a ‘whack’ at laying things out very quickly first. Then they would hover around the table and start moving work (story cards) around.

Conversations would surface around the most effective way to deliver the functionality – workflow, around risk mitigation and unknowns, around dependencies and integration milestones. Quite often the discussion would drive a new user story that was added to the mix. Typically these were what I like to call “glue stories” or stories that support the stream of features or functionality.

After perhaps an hour or so, the team would feel they had a nicely balanced workflow leading to a release point. Quite often they couldn’t fit in what the stakeholders had envisioned for the time frame, so there would be some negotiation and scope trade-offs. But in the end, they formed a release plan that felt feasible.

It was at this point that the stories were collected in order and they became a “Product Backlog”. At this point, they began iterating or sprinting.

The Product Owner role is a central figure in Release Planning and Road-Mapping at these higher levels. They work with the stakeholders on needs and with the team on the reality of delivery. Release planning converges these two perspectives into envisioned, prioritized, high-value bodies of work that align with release expectations.

It’s primarily the iterative nature of these planning activities that make me think the Product Owner has a wee bit of Project Manager in the role—no matter how folks respond to what they think that role entrails on traditional projects.

Wrapping Up

I’ve covered two of the four quadrants in this article. In part 2, I’ll cover the remaining quadrants.

So far we’ve explored Product and Project Management activity within the Product Owner role. If we simply stopped here, it would be a full-time and challenging role to fill. However, there’s still more to explore. Next time we’ll explore the Leadership and Business Analyst quadrants.

I hope you are beginning to get a feel for the depth and breadth of the role. And perhaps a newfound respect for your Product Owners in general.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

Footnootes:

Scrum Guide, October 2011 version, except from page 5
The firm Pragmatic Marketing has a wonderful framework that illustrates all of the aspects of typical, technical Product Marketing. It’s useful to reference this so you understand the depth and breadth of a Product Managers responsibilities.
In the agile methods there is a coherent warning against Big Design Up Front or BDUF. The problem is that you can’t adequately design anything without in code experimentation and implementation. So the agile methods come at this challenge with iterative architecture and design that is qualified by working code. LDUF is a healthier, iterative version—Lean Design Up Front. It implies a Just in Time and Just enough strategy. It also implies that your architecting and designing on the fly; proving your designs with working code whenever possible.
Click here to listen to our podcast: Josh Anderson and I co-host it. We’ve recorded 40+ open discussions where we chat about all things agile. There are several Meta-Casts where we’ve explore the role of the Product Owner and mentioned a quadrant-based view at the role and responsibilities. In Meta-Cast 40-41, we explore the quadrants in much more detail.

Is the Product Owner part of the Team?

Written by Robert Galen on May 28, 2013. Posted in Articles. 1 Comment on Is the Product Owner part of the Team?

As a Certified Scrum Coach (CSC), I belong to a CSC/Certified Scrum Trainer discussion group. The folks on this list are a relatively small group of coaches and trainers that are one of the driving forces behind Scrum.

They are thought leaders, evangelists, and practitioners. It’s an incredible group and I’m humbled to be a part of it.

As you can imagine, there’s always discussion and debate going on about the nuances of Scrum, Agile, and the associated practices. Sometimes it gets quite heated. I won’t share the specifics, but I do want to focus in on a thread that seems to come up quite often. The question:

Is the Product Owner a part of the Scrum Team?

It sounds like a simple question, one with a clear answer. However, it seems that it causes a nearly 50/50 rift in the above community. Now to be fair, the entire community doesn’t always “weigh-in”, so it’s hard to get an accurate assessment. But it certainly feels like a 50/50 split. And I find it somewhat confusing that such a small, but important point can have such ambiguity.

Before I weigh-in with my own opinions, I’d like to gather a few from well-respected resources.

A Few Opinions

From the Agile Atlas, I captured the following:

Scrum is a team process. The Scrum Team includes three roles, the Product Owner, the ScrumMaster, and the members of the Development Team. The Product Owner has responsibility for deciding what work will be done. The ScrumMaster acts as a servant leader, helping the team and the organization make the best use of Scrum. The Development Team builds the product incrementally, in a series of short time periods called Sprints. A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals. In each Sprint the Scrum Team will build and deliver a Product Increment. Each increment is a recognizable, visibly improved, operating subset of the product, meeting understood acceptance criteria and built to a level of quality called the Definition of Done.

And from the Scrum Guide , the following surrounds the definition of the Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

In both cases, the distinction is for the Product Owner role to part of the overall Scrum Team. I didn’t say the “Development Team”, but the overall Scrum Team.

So, Why Exclude Them?

In the discussions I’ve seen surrounding whether the Product Owner is on the team have circled the following four major points:

They’re not part of the team, so they don’t talk at the daily stand-up.
They can’t attend the teams retrospective. This is one point that gets the most traction. The logic goes that they can skew the discussions in the retrospective to be too business-centric or results focused. Rather than internally towards the teams’ improvement.
They’re too busy to engage with the team as a “team member”.
Their role is simply too different; that is they don’t contribute work to the sprint.

All of them concern me, but the second point most of all.

I clearly ‘get’ that the Product Owner role is separate from the Development Team in Scrum. I think that distinction is healthy and balanced. However, I don’t think the Product Owner (nor the Scrum Master) should be excluded from participating in any of the teams Scrum ceremonies or activities. Nor should they be precluded from speaking.

From my perspective, they’re a member of the team with equal footing in all areas as long as we support the inherent fundamentals of each role – role and responsibilities.

Why do I want the Product Owner ‘in’ the team?

So you might be asking, why do I feel so strongly about this point? It originates with the notion of agile being a “team sport” and the self-directed team aspects of creating high-performance teams. I think ‘teaming’ is a central component of the success potential. Here’s a short-list of reasons why I want the Product Owner to be “on the team”:

So they have some skin in the game
So they’re accountable for the teams’ success or failure
So they learn with the team
So they begin to understand the teams’ strengths and weaknesses (including their own)
So they attend ALL of the ceremonies and fully engage (as all team members should)
So they make themselves “available” for the team when they are needed
So they try to “sit with” the team
So they occasionally try and do some work within their team, for example, feature testing
So they invest in continuous team improvement; which includes: sharing the competitive/business landscape with their team – domain knowledge
So they celebrate success with the team

And I don’t intend this list to be exhaustive; as I’m sure I missed things. But surely you get a sense for the ‘why’ behind my concern and argument.

Wrapping Up

Can a Product Owner become too involved in the development process and create churn? Perhaps. Can they share business pressure with the team and push them to deliver too quickly? Sure. Can they become separated from the team due to job time constraints and appear to be disinterested? Absolutely.

Can the Scrum Master operate poorly? Can the Development Team operate poorly? A clear yes to both. But excluding them from the team is only one possible ‘solution’ for these challenges. I’d rather look at root cause and fix them than exclude folks from the team who are creating ‘churn’ or are operating poorly within their roles. But that’s just me.

Like I said, approximately 50% of the CST’s seem to want the Product Owner outside of the team. So, you’re not necessarily wrong if this is your model or posture.

However, I’ve just got a different view. AND, in my agile experience this model has always led to better results. When I refer to a “Scrum Team”, I personally like them to be “composed of”: a Scrum Master, a Product Owner, and a cross-functional team of “developers” who are sufficiently skilled to deliver on their Product Backlog and meet their Definition of Done. This to me is a TEAM, and anything that undermines that notion is something that creates a lesser result.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

Is there a “Place” for Business Analysts & Project Managers in Agile Teams?

Written by Robert Galen on May 7, 2013. Posted in Articles. 1 Comment on Is there a “Place” for Business Analysts & Project Managers in Agile Teams?

And if they belong there, what do they do? To be honest, I don’t exactly know.

It’s sort of the same question for other more ‘specialized’ roles like architects and operations engineers. They all don’t fit.

If I use Scrum roles as an example, there are ONLY three primary roles :

The Development Team
The Product Owner
The Scrum Master

That’s it. It’s simple and clear. There are no business analysts or project managers or testers or developers for that matter. There is only a team of individual skills that are tasked with executing a list of work—a Product Backlog.

They are asked to work together—producing “working code” in increments.

The team is self-directing; self-managing, and self-organizing. That implies that it’s pretty much up to the team to figure things out. Sure you can have managers hovering around the team and providing leadership, support and occasional guidance. But the best agile teams are pretty much left alone to deliver.

There is also the notion of generalization over specialization; in that you want the team to be as generalist as possible. For example, developers can design, write use cases or user stories, test, and deliver their functional contributions. So the broader each team member views their skill and responsibilities, the better. No hard silos allowed!

Call for Feedback

So, rather than my trying articulate whether they should or shouldn’t be in agile teams, I’m looking for reader feedback to generate discussion.

Do Business Analysts and Project Manager(s) have a place within Agile teams?
And if they do, what do they do? Seriously, what do they focus on?
How do they collaborate as part of the team? What are their primary roles? And contributions?
If they re-frame from “old role” to “new role”; what changes need to be made?

My sense?

My personal sense in both cases is that, yes, there is a place for Business Analysts and Project Managers within agile teams. Not leveraging their skills as they traditionally have, but more so transforming themselves to contribute within the context of an agile team. I would also argue that there are wider opportunities within agile teams to contribute.

But that’s just my perspective. What’s yours?

Thanks for listening,
Bob.

Don’t forget to leave your comments below.