Author: Robert Galen

Effective Scrum Product Organizational Patterns Part 2

Written by Robert Galen on December 16, 2013. Posted in Articles.

In part one of this series; I focused more on guidelines for finding and establishing Product Owners in your organization. In this article, I want to focus more on organizational dynamics. And this is probably more focused on larger-scale organizations with product lines, many products, and Product Owners aligned with all of that.

Agile Product Organizational Patterns (continued)

Connecting Hierarchy to Execution

I’ve found that the Product organizations that morph their existing organizational structures into something aligned with Agile / Scrum team execution do a better job of delivery. At the lowest level, that implies a series of Product Owners aligned with Product Backlogs per team. If you’re have more than one team delivering a product, then the Product Owners collaborate amongst themselves so that the work items all integrate into a holistic product.

Figure 1, Scrum of Scrums Hierarchy, courtesy of Mike Cohn & Mountain Goat Software

Think of it this way. Often the Product Organization aligns “behind” the Scrum of Scrum envisioned above. That is, the Scrum of Scrums is a team-based and execution model. However, for each level and team there is a Product-level connection:

At the lowest level, there is a Product Owner per team; driving their efforts with a Product Backlog that aligns with the teams skills.
At the Scrum of Scrums level, the Product Owners need to collaborate. Often there is a “Lead PO role”, where one of the Product Owners is guiding the aggregate view across the various Backlogs.
At the Scrum of Scrums of Scrums level, there is typically a Chief or Uber Product Owner who is connecting higher level business roadmaps and delivery commitments down to the teams’ executing them. They usually track and maintain the balance between perceived commitments and the actually velocity of their Scrum delivery team(s).

A good reference for Scrum of Scrums scaling, and the extensions the Product Owner Organization needs to make to adapt to feeding at-scale teams, is my book. Chapter 17 of Scrum Product Ownership delves into the Scrum of Scrums layering and the product responsibilities.

The essence of this pattern though is organizational transformation. Effective Product organizations re-connect their structures to how their technical teams are now delivering products. Along the way, they learn how to compose, decompose, and recompose backlogs that drive work through their Scrum teams.

Having a Scaling Model

There are several models now available for scaling agility. One of them is the Scaled Agile Framework (or SAFe) by Dean Leffingwell. The other is Disciplined Agile Delivery (or DAD) by Scott Ambler. Bas Vodde and Craig Larman have written a two book series on how to scale agile and scrum teams. And lastly, there is the venerable Scrum of Scrums model of which I’ve leveraged successfully to scale at many organizations.

Independent of the model, Product Ownership at-scale needs some sort of mechanism to move work from the concept and ROI phase (Portfolio) to the execution phase (within Scrum team(s)). Typically, all of the models implement a 3 level flow along these lines:

Portfolio Level – Roadmaps, High level Valuation & ROI, Strategy; towards…
Project Level – PMO, Project level costing & tracking, Metrics; towards…
Team & Release Level – Iterative Execution, Release Train dynamics, Feedback.

Often the upper two tiers implement a pull-based Kanban system for visualizing, maturing and organizing work for the teams. The team level is often focused towards Scrum. An important part of the translation from the Project tier to the Team tier is establishing a Release Train. This would be the tempo that the teams’ plan at for delivering project-level ‘chunks’ to your customers. Dean Leffingwell established the term/model in SAFe, but it’s become relatively pervasive in its use.

Independent of which specific model, effective Product organizations realize how incredibly helpful it is to establish and follow a model similar to those above. It helps in visualizing and flowing work from high level organizational goals towards your teams for execution. It turns out that the clearer the flow, the better the team and business results.

Product Owner – Community of Practice (CoP)

It turns out that User Story writing is a practiced art, as is effective story point estimation, as are many of the other aspects of Product Ownership. The best Product Owner organizations establish a Community of Practice model where their Product Owners gather and share examples, lessons, challenges, and tools they apply within their own teams.

I’ve seen the following activities be part of establishing a CoP for the Product Owner ecosystem:

Establishing “reading groups” for ongoing learning
Creating an “information portal” (Wiki) where external references and internal knowledge is documented and shared
Cross-attending other Product Owner meetings, focusing on Backlog Grooming and Story Writing
Comparing User Stories across teams; establishing some consistency in standards and sizing
Conducting a periodic meeting where Organizational Product Owners share challenges and create a Backlog for “steering” product agile evolution
Creating an Organizational – Product Ownership “Impediment List”

It’s often useful to establish a small core team of thought leaders who are leading and motivating the CoP’s direction and evolution. Typically, Scrum will be used to for this and a backlog is maintained that captures the specific goals for evolving the Community. The Chief / Uber Product Owner are often the Product Owner of this team and helps set the direction for the Community.

Another part of the CoP is surveying the needs of the teams and the Product Owners and supporting training and coaching needs across the organization. Many organizations often try to “go it alone” in their agile transformations and are reluctant to ask for ‘help’, Realizing this, community leadership can bring in training and internal/external coaches to augment the community and accelerate the learning and effectiveness of the organizations agile transformation.

Partnership between (Product + Technology)

Finally, this is one of the greater success patterns in mature agile product organizations. At the top, the two organizations realize that effective agile execution requires a partnership between the Product and Technology. Not only that, they understand that the planning, tracking and reporting aspects of project execution have now shifted to the product-side. There are now “no walls” to throw needs over to a group to plan a response. Both have to work collaboratively not only on the envisioning and requirements side of things, but also on the road-mapping, planning, and delivery aspects.

One way of illustrating this partnership is sharing a story. It comes from Chapter 18 – Other Scaling Model Considerations from ‘Scrum Product Ownership’.

When I was a Director of Development in a traditional Waterfall organization, I did the entire project planning for my development projects. The product organization would throw the roadmaps “over the wall” to my teams for execution. I would do the requirements analysis, project plans, negotiate with the product folks, and then commit to a plan.

In the end, I would throw the software “over the wall” to the quality group for testing & requirement verification. Then we would both throw it back over the wall to product organization for customer delivery.

While we were ostensibly an “organizational team”, our first loyalty was to our functional silo. But this posture fundamentally changes as you move towards an agile organizational transformation.

For example, during my tenure at iContact I found myself vetting our technology organizational development plans earlier and more collaboratively with the Chief Product Owner and the product team. For example, vetting team structures with them, aligning hiring plans with the roadmaps, vetting our skill set strengths & weaknesses and overall team development plans.

This even extended to how we aligned teams towards our products. We just didn’t throw people into teams, throw backlogs together, and then glue them together. No, it was much more thoughtful than that. This is the basic ordering of our thought processes over time:

1. It started with the product roadmap. Understanding what we were trying to accomplish strategically as a business. Looking at it from a technology perspective and trying to contribute (early) to the plans from our perspective.
2. Next we would look at the overall development and testing organizations, trying to determine numbers, skill-sets, and groupings to best connect teams and skills to product areas in the roadmap. All with an eye to efficient throughput of features.
3. Part of the above was considering Scrum Master and Product Owner ‘pairs’ for each team. Also, the nature (types of work) that each backlog would feed each team. Were we skill aligned? Consider this close to Feature Team and/or Component team alignment; although we didn’t directly leverage those notions.
4. We tried hard to give each team an identity or ownership of a complete area of the project or product. Ownership of maintenance, bugs, new development, support, dependencies, architecture, etc. We felt it important for each team to have a strong sense of ownership, which then aligned towards accountability.
5. We would also consider load balancing; were we balanced to product priorities across the roadmap as much as possible given our team size and capabilities? In these cases, we might create shared responsibilities (backlogs, architecture, etc.) across multiple teams.

In my traditional team experiences, we would never have partnered this way. But we did here within our agile contexts and it worked beautifully.

For those wondering if we lost ourselves in the partnership, I’d say no. We didn’t always ask for permission. And the product team valued our technical leadership capabilities and trusted our judgment. But we were much more collaborative and transparent than I ever was traditionally.

Wrapping Up

I began this two-part series vetting my frustrations with organizations trivializing the Product Owner role and Product Organization restructuring needs when adopting agile. In my experience, this is probably one of the Top 3 problems I encounter while coaching.

Often the excuses flow when discussing this part of the transformation; from we have no additional headcount to we’re too busy to work closely with our technical teams to we want to write everything down because we’re the only ones who know what to do. Many of these connect back to an inherent resistance to change.

What disappoints me the most is how short-sighted all of these excuses are. Many organizations don’t realize just how crucial the Product Owner is to their success, but it’s within a collaborative framework and not an “over the wall” relationship. And beyond that, they fail to realize that it’s a serious role in their agile adoption—one that needs investment, skills, and the time to focus towards the team.

In some small way, I hope I’ve provided some “investment advice” to Product Organizations who are contemplating “going Agile”. It’s certainly not a free ride, but the results are well worth the investment.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

Effective Scrum Product Organizational Patterns Part 1

Written by Robert Galen on November 26, 2013. Posted in Articles. 1 Comment on Effective Scrum Product Organizational Patterns Part 1

Roughly fifty percent of the organizations I visit who are “going Agile” struggle with the Product Owner role. I regularly encounter questions like:

Do we really need a Product Owner per team?
Why can’t our Scrum Masters also serve as the Product Owner?
Since our Product Managers are way too busy, why can’t we simply make our Business Analysts the Product Owner?
Can’t the team simply create its own work? Especially since they’re self-directed.

The first hurdle these organizations are encountering is the investment it takes to provide adequate vision and clarity for their technical teams operating in an Agile/Scrum environment. Often they want to describe things very early on (traditional software requirements) and then walk away until the team delivers exactly what they asked for or need.

And they want a minimal level of interruptions from the team. Since their Product Managers (Owners) are customer and stakeholder facing, with simply no time to engage the team as they work. Simply put—the teams need to correctly interpret the requirements, as defined, and get on with building the products. Continuous collaboration, while it sounds good theoretically, is not possible given their real world constraints.

This role trivialization and denial surrounding the engagement and importance of the Product Owner role pervades many of these organizations. They’re constantly looking for short cuts and workarounds so as to minimize team contact. For the life of me, I don’t understand why.

In this two-part article I want to discuss the organizational posture surrounding effective support of Scrum and the Product Owner role. I might go as far as to say that if you’re unwilling to make these investments, then don’t bother “going Agile or Scrum” as your results will certainly suffer.

My goal is to explain how many organizations should invest in their adaptation towards Scrum Product Ownership. But in the end, each organization must be willing to “pay the price” of agility done well…

Where do Product Owners come from?

I think this is the first question you should be asking when you’re contemplating moving to Scrum. As part of forming your Scrum teams you’ll need to find one Product Owner for each of your teams. Where in your ranks do they come from? Well, typically I see them as part of your Product Organization, so Product Managers become Product Owners. Other team members in Product Marketing and Product Management organization are ‘converted’ as well.

In some organizations, the Product Organization is “lagging behind” the Technical Organizations’ agile adoption. In these cases, the technical organization often provides the Scrum roles of Scrum Master and Product Owner. I’ve seen Business Analysts and other requirement facing designers tapped as Product Owners. Also, architects and testers are selected because of their breadth of understanding of the product functionality and customer landscape.

All of these individuals can BE a Product Owner as long as they have the requisite skills for the role. We’ll explore the 4 quadrants of the role next to illustrate the skill set.

However, beyond skills, there’s an important connection when the Product Owner is not in the Product Organization proper. They need to be strongly empowered and connected to that organization. You can’t be a decisive, empowered Product Owner when you always have to ask permission or run something by another organization for every decision. It simply doesn’t work.

So strong “dotted lines” for communication, inclusion in strategy & tactics, and empowered trust are important aspects of the Product Organization extending towards these liaison Product Owners. And beyond this, I view this as a temporary state. At some point in your strategy, the Product Organization needs to be finding, staffing, and directly guiding the Scrum Product Owners.

In a phrase, they need to have “skin in the game” in the agile transformation; and the sooner the better.

Skills Sets

In a previous article, a 2-part series actually, I explained the 4 Quadrants of Effective Product Ownership as a way of identifying the core skill areas for the role. I’ll briefly run over them here, but I would recommend you read that series.

There are four critical skill areas for the Scrum Product Owner, including:

They are part Product Manager, in the Pragmatic Marketing sense
They are part Project Manager, in the PMI sense
They are part Leader, in the Leader vs. Manager sense
And they are part Business Analyst, in the IIBA sense

The first thing you should notice is the breadth of skill required for effective product ownership. The Product Manager, Project Manager, and Business Analyst are all common, full-time positions in regular teams. So, the amount of work a Product Owner is responsible for may exceed one person’s capabilities to deliver. Often Product Owners only have some of these skills and it’s up to the Product Organization to supplement them in some way, but more on that later.

Now I want to move into the core of this series. Let’s explore some patterns that surround agile product organizations.

Agile Product Organizational Patterns

Next I want to explore a few successful patterns that I’ve seen emerge from organizations that understand the proper balance between the technology and product organizations when they’re implementing Agile / Scrum. Mostly these apply to larger scale or distributed organizations, but many of them apply equally well to smaller organizations or start-ups. And while they aren’t guarantees for success, they certainly improve your odds of a successful agile transformation.

Supplementing Product Owners

It’s an often assumed position that there can be only one Product Owner per team. The logic goes that there needs to be a single deciding voice guiding each Product Backlog and therefore team. I agree on the ‘voice’ part, but I think it’s incredibly difficult to find an individual that can meet all of the requirements of the 4 Quadrants. In my experience, it’s virtually impossible. So then, how do we fill the role?

I’d say in aggregate. We need to have a lead Product Owner for each team, but we can certainly complement their skill areas where necessary. A common complement is to attach a Business Analyst to Product Owners (actually they’re part of the team) to help them in crafting User Stories for their Backlogs. Now the BA might be ‘shared’ across multiple Product Owners, but the effect is to create more consistent and better backlogs.

I’ve seen the same approach taken when augmenting the planning aspects of the Backlog, with either the Scrum Master helping out or assigning a ‘shared’ Project Manager across a set of Product Owners. Typically, the alignment revolves around multiple teams working on a singular product or project. Where cross team integration and planning, across the Backlogs and the team, can be a challenge.

The key is for the Product organization to supplement their Product Owner skills so that they can actively support their teams across the 4 Quadrants. Making this investment important is a hallmark of this pattern.

It’s a Full-time Role

Effective Product Ownership is a craft, a profession, and a discipline. It’s not a part-time, do it when I feel like it, role. I believe it starts with crafting job descriptions for the Product Owner role. That’s why I wrote the 4 Quadrants in the first place, to help describe the broad nuance of the role. Effective organizations look at their current product management and marketing roles and hierarchy and then craft a new role for the Product Owner.

In many cases, this means you’ll need to go out into the market place and hire some experienced Product Owners to complement your existing staff. It also means you’ll work with the technical organization to identify others to serve in a supplemental role as I described earlier. Often these folks are Business Analysts, Designers, and Project Managers.

And it means that by and large, you’ll have one Product Owner per Scrum team. I’ve successfully overloaded the role to two teams, but carefully and with the permission of the Product Owners. A prime directive for the successful Product Owner is to “feed their team well”, and they need the time and skills to do so.

The core of this pattern is honoring the complexity and importance of the role and remembering that it’s full-time!

Outward – Product Manager vs. Inward – Product Owner

At iContact we tried several variations of organizing our Product Owner team over time. When we first implemented Scrum, we simply “converted” our Product Managers to Product Owner roles. We didn’t reframe any of their responsibilities, so they quickly became overloaded—essentially with two distinct jobs.

We initially handled this overload by supplementing them with “help”. For example, giving them Business Analyst or Project Management help, so that they had more bandwidth to do all of the requisite aspects of their roles. This worked relatively well, but they were still quite overloaded, which affected their focus.

After a few years we hit on a recipe that seemed to work best for us. I’ve also seen it as an increasing pattern in many other organizations. We split up our Product organization into Product Owners, who faced the team, and Product Managers, who faced the organization and the customer. We created a reporting relationship where:

A Chief Product Owner would own many Products or Product Lines.
A Product Manager would own a Product Line or Product; Product Managers would focus primarily on roadmaps, product strategy, external communication, and release planning.
One or several Product Owners would “report to” each Product Manager; Product Owners would focus on their Product Backlogs at they supported the Roadmaps and cross-team dependency management.
Teams would be aligned around Product Owners; then to each Product

This allowed us the focus we needed between the internal and external demands of the agile product organization. It also allowed us to create better “career paths” for our product managers & owners. While on the surface this may seem “wasteful” from a headcount investment perspective, please don’t look at it that way. It turned out to drive great products and solid growth, so it was an investment well spent.

Wrapping Up

I began this article talking about my frustrations with organizations trivializing the Product Owner role and Product Organization restructuring needs when adopting agile. In my experience, this is probably one of the “Top 3” problems I encounter while coaching.

I want to challenge these excuses. The Product Owner role is crucial to your agile transformation. It’s central to the team and to the organizational. It’s the “glue” that binds high level strategy to low level execution. To short-shrift it, is to undermine your very goals.

In the second part of this series, we’ll explore more organizational scaling patterns for how the Product organization should respond to agile at-scale.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

10 Indicators That You Don’t Understand Agile Requirements

Written by Robert Galen on November 5, 2013. Posted in Articles.

I presented at a local professional group the other evening. I was discussing Acceptance Test-Driven Development (ATDD), but started the session with an overview of User Stories. From my perspective, the notion of User Stories was introduced with Extreme Programming as early as 2001. So they’ve been in use for 10+ years. Mike Cohn wrote his wonderful book, User Stories Applied in 2004. So again, we’re approaching 10 years of solid information on the User Story as an agile requirement artifact.

My assumption is that most folks nowadays understand User Stories, particularly in agile contexts. But what I found in my meeting is that folks are still struggling with the essence of a User Story. In fact, some of the questions and level of understandings shocked me. But then when I thought about it, most if not all of the misunderstanding surrounds using user stories, but treating them like traditional requirements. So that experienced inspired me to write this article.

In a small way, I hope it advances the state of understanding surrounding the proper use of User Stories. So here are ten indicators that you might not be looking at your stories the right way:

#1) Writing a complete story all at once – trying to estimate and get it “right” the first time

Stories evolve as they move closer to sprint execution and as they can decomposed and further refined. I consider a good heuristic that a team should “visit” each story (and its offspring) about 3-4 times before they make it into a Sprint or iteration. This would include grooming meetings and also discussions across the team.

I really want teams to take ownership of their backlogs in real-time—thinking about upcoming stories, themes, their interrelationships, and design & testing strategies. Having this occur on a daily basis creates the emergent nature of agile requirements, design, and planning.

#2) If the Product Owner asks for something not articulated on the story, you split the story and make them wait for the “additional scope”

The expectation here is that once the story enters a Sprint, there is no “scope creep” allowed. That everything needed up-front definition. If the Product Owner forgot something or wants to react to some implemented functionality, tough. They get exactly what they asked for and changes get deferred to a new story in the next Sprint.

I disagree. User Stories are intentionally ambiguous; intentionally incomplete. I use the heuristic that stories should enter the Sprint at 70% clarity and exit the Sprint at 100% clarity. The point of the 70% is that there should be ambiguity – so things are discussed, clarified and determined during the Sprint. The requirement emerges based on conversations. This should not be penalized or deferred; instead it’s the “way of things” in agile requirements.

#3) Allowing stories with very minimal or trivial Acceptance Tests to enter your Sprints

One of the more important parts of the User Story is actually on the back of the card—it’s the Acceptance Tests or Acceptance Criteria. Establishing these conditions for acceptance early on help focus the team on the purpose and important bits in a story.

The help the developers design for what the customer values. They help the testers ensure the stories’ functionality meets expectations. They help the Product Owner verify acceptance, Done-ness and then move on. They speak to functional and non-functional requirements.

A bad example of a set of acceptance tests would be having one that says: “the story is accepted when the Product Owner signs off on the story”. You can’t imagine how often I see variations of these singular acceptance criteria. I have a heuristic that says a story should have a minimum of 5 acceptance criteria and at least one of them should be non-functional. If it’s a technical story, I look for most of the acceptance tests to be non-functional.

#4) Writing ALL stories with the [As a – I want – So that] format, even if it takes an hour or more to do so

Anything that you take prescriptively and do it “just because” we’re supposed to is probably a bad idea. Context matters in software teams—especially in agile teams. The standard format for writing User Stories is incredibly useful. In fact, I normally want to see teams leveraging the outer clauses of persona and business why, simply because they add so much value and nuance to the story (and the discussions).

However, I’ve seen teams often succumb to the tyranny of the story and feel compelled to write all of their stories in this format, even when they don’t truly fit. For example, I don’t know if technical stories truly fit this format. Sometimes all I want for a technical story is a definition and then strong emphasis on the acceptance tests (or how we’ll know when the story is complete). And that seems to be “good enough”.

At the end of the day, the story needs to have “words” that have meaning for the team to interpret, estimate, and execute towards delivering what the customer needs. It’s as simple as that!

#5) Believing User Stories are only for functional work (features, customer facing functionality) and not for anything else

There’s an illness in User Story writing that I want to cure. It goes by many names, but most popularly it’s called feature-itis. It’s an insidious disease that creeps up on you. The most significant symptom is backlogs that contain only feature-centric User

Stories. There are no others to be found. No stories focused on infrastructure, technical debt, bug fixing, test automation, refactoring, design, research spikes, nothing.

While the customers LOVE this disease, it ultimately does them a disservice. It creates narrowly focused products that are typically very fragile. The investment in quality in all dimensions simply isn’t there. Here’s a heuristic for your stories, all work should be crafted in stories and it should always be balanced beyond—just features. If you lack discipline, perhaps use the 80:20 rule to help; 80 percent features and 20 percent internal investment.

#6) Having a goal to get as many stories done as possible within each Sprint; so heads-down get to work

What should be the goal of each Sprint? Story count, points produced, meeting the Sprint Goal? All of these are primary targets. In my workshop, the gentleman used this example. He said what if:

The product owner changed their mind during the sprint. When they thought they wanted a blue background, but in reality then asked for green. Or asked for green, when they hadn’t specified it in the first place?

His suggestion or response was to split the story. Deliver what was clearly defined and then rework the additional story later. That delivering the story was the primary goal. I.e. meeting the plan or gaining the points.

I had to disagree with him. I didn’t look at this event as a ‘fault’. I looked at it as the normal way of things as the story requirements emerged. The answer should be: listen to the customer, change it to green, and deliver the story. From my perspective, the customer “drives” in agile teams. And we should primarily measure ourselves by delivering customer value.

#7) Feeling that stories have to be complete (100% understood, written, explained) before they enter a Sprint for execution

Teams are afraid to say “I don’t know” and “We need to do some additional research, prototyping, and experimentation to more fully understand this story and how to decompose it”. Instead, they write based on assumptions. The focus is on filling in the template and going through the motions to get a complete story. Very often this takes an incredible amount of time and the team “drops into” design discussions.

What’s insidious about this is it gives the team a false sense of security. As in – they now know everything about the story and the rest is simply “implementation details”. But that was never true in Waterfall requirements and its certainly not true here.

Remember the 70% clarity heuristic from #2.

#8) Teams “hold onto” stories until the very end of a Sprint, demo them, and receive feedback on the acceptance of the stories

This reinforces that view of a complete story that is developed – then tested – then demonstrated – then accepted serially through the sprint, which is probably not the best strategy. I much prefer to be demoing and interacting around stories all along their evolution within the Sprint.

In fact, there is the notion of a “Triad” in User Story collaboration; the three players being the Developer(s), Tester(s), and the Product Owner / Customer(s) all collaborating around the story. Questions are raised, clarifications are made, and the stories evolve. Only upon exit of the Sprint is the story at 100% clarity.

#9) The Product Owners must write the stories until the team “accepts” them as well-defined

I’ve seen this pattern over and over within many less experienced agile teams. Since the Product Owner ‘owns’ the backlog, then it’s their responsibility and theirs alone to write all of the stories. And beyond that, their work isn’t “done” until the team accepts the story as meeting their vision on completeness and clarity.

I say hogwash to this! Yes, the Product Owner is the final arbiter of the backlog. However, the WHOLE TEAM needs to contribute to the backlog. And the team is not some gating factor for “perfect stories”. That’s simply a Waterfall requirements mindset seeping back into the team’s behavior. Instead, everyone is responsible for getting their stories ready for execution and delivery.

#10) Thinking that estimates are only good for planning purposes

One of the best ways to move forward in understanding and decomposing a User Story it to throw an estimate via planning poker. Do it as soon as you can. Then have that wonderful discussion around the team as to what they’re thinking surrounding the estimates. Teams too often debate the nuance of a story that’s too large or complex for far too long. I like to estimate as quickly and as often as possible. It usually leads to insights at what to do with the story—break it down, run a research spike, let it alone, have some off-line discussions, etc.

Always remember, the most important ‘C’ in the 3-‘C’s of User Stories is the “conversation”. That’s the same goal for planning poker; less about the estimates and much more about the conversation(s).

Wrapping Up

I think the primary misunderstanding surrounding User Stories is that they evolve towards clarity; that you have the freedom to NOT define everything in advance, but to explore the requirements. The requirements, understanding, design, coding, testing, integration, defect repairs, and maturity of each story EMERGE over time. In other words, we’re lean in our thinking leading to just enough, just-in-time definition and delivery.

Now if we can only leave those ingrained Waterfall requirement behaviors behind us!

As always, thanks for listening,
Bob.

THEY… Made Me Do It!

Written by Robert Galen on October 15, 2013. Posted in Articles.

I was attending a Backlog Grooming session with one of our teams. I was simply observing as a coach, as the team had a solid Product Owner and Scrum Master in the meeting. It was generally my habit to “wander around” across our various teams and sit in on Scrum ceremonies as much as I could. Usually, as in this case, I just sat quietly. Observing the “goings on” and seeing if I could provide some offline guidance to our Scrum Masters.

In this particular session, the team was leveraging Planning Poker to estimate the amount of work in a series of User Stories on their backlogs. The discussions were going quite quickly, as the Scrum Master would put an egg timer on each story for 5 minutes of discussion, estimation, and “next step” decision-making. The point of examining each story was not to “complete it” in that one grooming session, but to advance the understanding of it and, if it was not a Sprint-Ready story, to decide what the next step in its evolution needed to be. The teams in general were quite good at staying on-point and not drilling too far into each story.

I did notice something though. There were two patterns “in the room” on a story by story basis. One was that the room seating layout was odd. The “developers” seemed clustered at one end of the conference table and the “testers” at the other. The developers seemed to be estimating as a group and the testers seemed to be following their lead. So if the developers gravitated towards a story being 3-5 points, the testers would most of the time wait a bit and then agree with the developer’s estimate.

On the rare occasion when the testers disagreed on points (level of effort, complexity, etc.) for a story, there would be heated debate across the two groups and quite often (almost always) the developers would drown out the testers concerns and they would acquiesce to the estimate. Then the timer would expire and the team would move on…

The other pattern surrounded Randy. Randy would often start out with an extremely high estimate, higher than everyone else in the room. When he discussed the ‘why’ behind his estimates, it was rarely driven by concrete experience or specific reasons. Typically, the rationale was simply:

This sounds like an awful lot of work and if I have to do it, it will take me a very long time!

As discussions unfolded, Randy would never move from his initial estimate. It seemed like he was simply ‘stuck’ there. Eventually the team would need to agree on an estimate and Randy would begrudgingly succumb to the estimate. Then the timer would expire and the team would move on…

Randy had another mode of operation. Often he would flip-flop and “go low” on his estimates. Often the language surrounded things like:

If we hack this together and skip testing these specific conditions, then I could see us doing this 20 point story in 2 points. In fact, if we work overtime, we could do it in 1 point.

When the team confronted Randy on his oscillation, his rationale was always driven by THEY. As in:

They’re going to cut my estimate or not listen to it anyway, so I need to go high. Or they’re not going to give me enough time or trust me to do a good job anyway, so why should I worry about doing things right?

No matter how hard the team tried to get Randy to be more “balanced” in his views, it never really helped. Then the timer would expire and the team would move on…

Who are THEY?

In the first example, the testers THEY were the developers on their team. The testers weren’t comfortable debating them on story scope or holding the line when they felt something was larger than the developers thought. In their retrospectives, it turned out that quite often the tester’s impressions of relative size, their instincts, were much more accurate than the developers. This was probably due to them considering all aspects of a story and not simply the development time.

In the second example, I believe Randy’s THEY was his historical experience with pleasing folks and dealing with demanding and poor leadership. I also believe the roots were well before he ever came to iContact. Randy was riddled with FUD – fear, uncertainty, and doubt regarding the organization and leadership. In the latter case, he would low ball the estimates because he felt that THEY couldn’t handle the truth of real estimates. He basically would say what he felt folks wanted to hear.

His oscillation was around frustration. So occasionally he would ramp up the estimates and try to hold the line—no matter what. So, he would fluctuate between too high and too low estimates, neither of which he believed to be true.

I remember stopping Randy in the hall once and asking him to “tell more truth” around his estimates. And to trust me more, in that I meant what I said around agile principles. What I wanted, as the leader of the technical organization, was for team members to analyze the story and to estimate what it would take to do a well-engineered, high-quality job. A job that they could be proud of! I remember him telling me that leadership (THEY) didn’t want that. Instead, they wanted low ball, cut corners, do it as quickly as possible estimates.

I stopped him and said that, in this case, I am THEY. And I’m asking him to estimate with truth, quality, and craftsmanship in mind. So there is no THEY in this case; there is only ME and I’m asking you to do what I’m asking.

While we had this discussion on several occasions, I don’t think Randy ever got (or at least believed and trusted) that message. Whatever baggage he had—he continued to carry. I recall when he left iContact, I was hopeful that he would leave THEY behind him and start with a fresh perspective in his new team.

Other They’s

In the same grooming meetings as I mentioned in the beginning, often the Product Owners would have their own THEY. In their case, THEY were Product organizational leadership. And THEY were telling them to put pressure on their teams and themselves to “get more done”. That the leaders had prmised customers more features and this pressure then would cascade down to the Product Owners on the individual teams.

How would this emerge in grooming? In a wide variety of ways:

Often they would second guess the estimates of the team. Looking for ways to get them lower. They would apply questioning, pin one team member’s view against others, and simply keep asking for “better” estimates.
They would also put pressure on the team to take on “stretch items” as part of every sprint. Then, once the team accepted them as “stretch”, they became firm commitments for the sprint.
It created a sense of tension in the team, where the Product Owner would be very feature focused and not want to take on any bug fixes, refactoring, or other technical debt work within the sprint.
Keeping people busy was the overriding theme and not delivering high value, high quality work in a balanced fashion. So if anyone had an extra second, the Product Owner looked to “fill it up” with something.

What was most insidious about this interaction was the sense of distrust and lack of collaboration it created between the Product Owner and the team. In this case, Product Owners allowed the THEY to breakdown their team relationships, which was very sad.

Wrapping Up

One of the five core Scrum values is Courage. I wrote another blog post surrounding that attribute that you might find valuable. But I do think “courage” has something to play in the above scenarios. In these cases, you’ll hear me talk about:

“walking your talk”;
“telling truth”;
“sharing your gut feelings”;
“filtering less”;
and “telling it like it is” as the most congruent things you can do.

Often it can be extremely hard to be balanced within your teams. But it’s what they need most from each of you.

I want you to ask yourself if you’re doing things for them? Or are you doing it for yourself? Have the courage in your agile teams to speak the truth and tell it like it is. Don’t succumb to THEY, THEM or even ME. Simply be true to yourself. I hope that the testers, Randy, and Product Owners have discovered this in their paths.

As always, thanks for listening,

Bob.

Story Context
This is another in my series of stories from my days at iContact. I spent time there from 2009 – 2012 working as the Director of Software Development and Agile Coach at this wonderful and mature startup. During that time we grew to approximately 300 people in size, with roughly 100 in Technology. The product space was a SaaS, email marketing application. We had about 8-12 teams that were practicing Scrum and Kanban for roughly 4+ years, so a relatively mature agile instance. Since I’ve left the company, iContact was acquired by Vocus. These stories are rooted in the experiences I had coaching and collaborating with this wonderful group of agile practitioners.

Don’t forget to leave your comments below.

Anchoring your Product Backlogs

Written by Robert Galen on September 10, 2013. Posted in Articles. 1 Comment on Anchoring your Product Backlogs

Not All User Stories are Created Equal

If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a book about Product Ownership and I spend a great deal of my time up to my eyeballs in stories and backlogs at various clients.

One of the things that frustrates those clients is that there are very few “prescriptive rules or firm guidance” when it comes writing stories and crafting Product Backlogs; in many ways, it’s more art than science. It’s also a practiced skill that gets better the more you actually do it—of course as a team, which is also true of agile estimation.

Quite often I see Product Owners define a list of “stories” solely by themselves. Sometimes they’re creating them from scratch. Other times, they’re decomposing a traditional requirements specification into small stories. While both of these activities are all right to “seed” a backlog, they miss out on the collaborative part, the team-based discussion and evolution part of the User Story. While story writing is a big part of the Product Owners’ role, I prefer them to do most of it collaboratively. I use the analogy that it “Takes a Village” to create and maintain a healthy Product Backlog and my experience largely supports that mindset.

Another challenge…

Effective story estimation and deciding when you stop decomposing stories is another challenge. Some coaches influence their agile teams to break their stories down into very small chunks, for example, work that can be done by one or more members of the team in a day.

This could result in a sprint being composed of 25-35-more individual, 1-2 point stories. From a decomposition position, this is wonderful. Everything is finely grained and extremely understandable. So on the surface, this “feels right” for many teams. However, I have a problem with it from several perspectives:

Having finely grained stories inhibits the team’s ability to swarm around the work
It often leads to very disjoint Sprint Reviews or Demos. Yes, work is being demonstrated, but how it all “fits together” is often impossible to demonstrate or communicate.
From a release or feature perspective, it’s hard for the customer to understand what the team has just accomplished—relative to the end goal.

Now we could go to the other extreme and have the team work on a 25 point story. That would alleviate some of the above challenges, but now it would introduce too little granularity and higher risk for the team. Clearly not everyone could work on the one story. And what if they underestimated it and it was 50 points?

What I’m alluding to is a “happy medium” between loading a sprint with one great big story and a series of incredibly small stories. It sounds like that might be the best strategy. But how do you “get there”?

That’s where I’m going next.

Boulders – Rocks – Pebbles

At the risk of repeating myself, I published a blog post in 2011 that talked about sizes of User Stories as you’re conducting your backlogs. The reference was to an analogy of story sizes as they were groomed and approached sprint-level execution. The three levels of story sizes were:

Boulders – Very Large stories; synonymous with Epic
Rocks – Medium to large stories; small Epics or larger stories
Pebbles – Small stories; ready for execution

I’ve found the analogy useful when describing the pattern of “breaking down” or decomposing User Stories during Backlog Grooming sessions with the team. And that’s useful, but I want to introduce you to another view to help you with prioritizing your Product Backlog by considering story sizes and themes.

Anchoring your Backlog Prioritization

I’ll start with a real-world example:

While I was working as a coach at my old company, iContact, we noticed several things in our grooming, estimation, and Sprint Planning. Let me share some of them in a discrete way:

Our Sprints were 2-weeks in length; our team sizes surrounded the classic 7 +/- 2 of Scrum
We implemented a Release Train of 4, 2-week Sprints and then a single “Hardening” week before we would push to Production; so roughly a quarterly production release tempo
We used story points for estimation; the classic modified Fibonacci sequence were the units
We noticed that a 13 point story “would fit” into a 2-week Sprint. A 20 point story would not. We started using the term: executable story for any User Story from 1 – 13 points, in that it would “fit” into a Sprint.
We also noticed that 2-13 point stories were never successfully delivered from a Sprint, even if the teams velocity math supported it
Our velocity was on average 25 across 10 teams. Lowest being 22 and highest being 29.

Our Product Owners started managing their Product Backlogs with these patterns and characteristics in mind.

For example, they came to the conclusion that each sprint could sustain a leading story of significant size—for example, an 8 or 13 point story. They considered this the anchor story for the Sprint. The next thing they would consider was finding support stories for the anchor story. Clearly size came into play in both of these cases, so as the team was grooming, breaking down, and estimating stories, they looked for anchor and support stories in clusters.

Anchor stories would drive the major theme for each Sprint and connect to the Sprint Goal and the Sprint Demo. Once they found a cluster of them (anchor and support stories) that would fit into a Sprint, they would look for other stories to “surround them” to fill the teams average remaining velocity. A typical example of this might look like the following:

13 point Anchor Story
8 point supporting Story
3 point filler Story
1-2 points infrastructure Stories

for a team with ~ 26 points of capacity. Before we’d started doing this, it was common for our stories to be much more finely grained and to be disconnected from each other. Finding clusters that would have demonstrable customer value was difficult. And we felt that we were stuck in the minutia and not seeing the big picture.

If you extrapolate this a bit, each team would be grooming 4-6 stories for each Sprint or 16-24 stories for each release. From a grooming point of view, this made it much easier for the team and the Product Owner to get their “brains wrapped around” a release. It contained a relatively small set of stories focused on Minimal Viable Features (the Anchors) and a supporting cast of stories.

Each Product Owner approached their Backlogs with the notion that a release could contain (at most) 4 anchor stories with an appropriate supporting cast. These “must haves” helped laser focus each release.

It also helped stop teams’ from overcommitting to too much work.

Improved Contingency Discussions

One advantage of this approach was that it simplified our discussions and trade-offs when we ran into trouble within a Sprint. Our options to jettison Sprint scope ran from the filler and infrastructure stories first. Then we would tradeoff supporting stories if we had to. The goal was always to hold the anchor stories “dear” and deliver them whenever possible.

Since there were only 4-6 stories totally “in play” it provided quite a bit of clarity around our options. That wasn’t the case when we had more finely grained stories in play.

Here’s a tabular view example of how we approached planning a release. Once we filled in the table, it would then drive the prioritized list of stories on the Product Backlog for each team. In essence, there would be 4-clusters of Anchors, Supporting, and Filler/Infrastructure stories from each team for every release.

Q1 Release	Anchor Story	Support Stories	Filler Stories	Infrastructure Stories	Points
Sprint 1	Setup ATM/Web Admin – 13 points	Authenticate – 5 points		Visual Dashboard – 8 points	26
Sprint 2	Setup ATM/Web Accounts – 13 points	Associate accounts – 5 points; Beneficiary – 5 points	Refactoring legacy authentication – 3 points		26
Sprint 3	ATM/Web account deposits – 13 points	Confirmation / receipts, close loop back to main account management system 5 points	SOA extension for Web / deposits 5 points	Need to test SOA interaction and deposit security 3 points	28
Sprint 4	ATM/Web account withdraws 8 points	X-site balance check – 5 points Limits check – 3 points Money handler	Pre-release bug fixing – 5 points	New money dispenser interface – 2 points Money loader – 1 point	24
Hardening	1 week of Hardening effort ;	Pre-release Testing & late defect repair; Support training			13

Figure 1, Example Release Plan – Backlog using Anchor Stories

Advantages

When we applied this approach, we recognized some distinct improvements in our story writing, backlog grooming, sprint, and release planning. Not that we were doing them poorly. In fact, we were fairly mature. But it helped us get to the “right level of abstraction” when dealing with our backlog workflows. Here are some of my observations on the advantages:

It streamlined our Backlog Grooming. Once we found appropriate anchor and supporting stories, as long as they were “executable”, we stopped breaking them down. It not only cut the number of stories “in play”, but increased the quality of our discussions surrounding the stories for each Sprint.
It better aligned the teams work to their Sprint Goal and it better aligned the teams work to their Sprint Demo. In addition, it drove more meaningful and impactful demo’s—making it incredibly easy to “connect the dots” from the Sprint Goal to the Demo.
It allowed for more swarming around the anchor and supporting stories; it’s really, really hard for a team to “swarm” around a set of 25-1 point stories within a Sprint. In our case, our anchor and supporting stories were places where the team could really swarm / pair / collaborate around the work.
It allowed for more look-ahead; a team would only have to look at ~ 25 stories to get a grip on a quarterly release. So we found ourselves grooming ahead to detect necessary story spikes and dependencies that needed to be managed. In fact, we were largely groomed for the next release by the third sprint of the previous release.
It helped us better deal with “complexity”. Typically, complexity was in our anchor stories. Quite often the team would need a Research Spike to clarify the anchor. We felt this was time well spent from a design and quality perspective.
Sprint Planning, in a word, was incredibly smooth. The sprints we composed of a small number of stories. The goal was clearly linked to the anchor story. And we always planned for the demonstration as part of Sprint Planning. In fact, we always knew the relationship of work from one sprint to the other as well.
By definition, this approach is goal-oriented and keeps the Product Owner focused on a Minimal Viable Feature for each Sprint, and a Minimal Viable Product increment for each release.

Wrapping Up

Nowadays, I often see teams dealing with far too many stories at a time. I was coaching a team not that long ago where their story mix was on the order of 1-2-3-5 points at most. In fact, most of their stories were in the 2-3 point range. Their average sprint velocity was around 30-35 points; so that meant they were dealing with 10-15 stories within each sprint. Their release train was undefined, so a teams’ release might encompass 80+ stories.

Their sprints were sort of “all over the place”. The teams lost their focus. Their story boards were incredibly complex and busy. It was hard for them to keep a view to prioritized business value. Sprint planning meetings were long, arduous, and often drove too far in the weeds. Complexity and technical risk was distributed across stories—so hard to determine. They rarely saw the opportunity for a story spike to gain a sense of understanding.

I introduced them to this notion and met a lot of resistance. They mentioned that their previous agile coach had told them to break their stories down into fine detail. They felt this was the right granularity for them—so their efforts could be tracked and reported on a near daily basis. I tried hard to “unwind” them from this perspective with limited success. I told them that they were breaking things down in advance of the sprint and that the sizes gave them a false sense of security.

But there’s a balancing act to be struck.

Sometimes large stories are just fine as-is. They are more understandable and estimatable. They also drive spikes when appropriate and allow for a team to swarm around the story. Most importantly, they allow the details to emerge just-in-time within the sprint, rather than trying to sort through everything in advance without working on code.

At the very least, I was looking for them to simply try this approach and see for themselves if it would be helpful. That’s where I’ll leave it to you. If you find yourselves writing, planning, and executing your stories at a fine level of granularity, consider stepping up a level. It might anchor you to better execution and delivery performance.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.