Tag: Scrum

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.

It’s the End of the Business Analysis World as we Know it? Part 5

Written by Steve Blais on July 30, 2013. Posted in Articles.

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Chapter 5: Wherein the business analysts encounter the Scrum Master, Scott discloses his concerns about business analysts and Verna summons

The organization was quite dynamic. Meetings were held in the hallways and corridors of the vast headquarters on a more frequent basis than in the meeting rooms. This might be considered by some to be an agile practice since the meetings were held not only standing up, but moving along, which meant that the meeting had to be completed by the time one or more participants got to their destination or their ways parted.

Thus it was that Brian and Ann attended meetings that morning. Brian ran into Ann as he came out of the elevators after arriving at work, his black Swiss Army backpack slung over one shoulder and a cup of coffee in his hand. Ann had had an earlier morning meeting with Belice Despacio who was assistant to the CFO. Ann was presenting the information she had amassed on the efficacy of buy versus build decisions on the Backbone project. She considered it her ‘kiss-off’ project for the organization.

“I don’t know about you, but I’ve been avoiding people like the plague these past couple of days trying to get things in order.” Brian greeted her.

“Me, too. You mean you haven’t seen Ken or Scott?”

“Not yet. But it looks like the waiting is over.” Ken came down the hall toward them.

“Shall we make a break for it? If we run in different directions one of us will get away.” Suggested Ann.

“It’s all right, kid.” Said Brian doing his best Bogie imitation. “They’d find us wherever we went. We gotta stay here and face the music.”

“It isn’t even High Noon yet.”

“Well,” said Ken with a vacuous smile. “It’s the Last Brigade, or maybe I should say Lost Brigade? I see that you have managed to infiltrate your business analysts into the projects anyway.”

“Nope,” said Brian continuing to walk. “There are no business analysts on the Backbone project. There are new developers who used to be business analysts and there are product owners who used to be business analysts.”

“And there are impact analysts working with the product owners,” added Ann.

“Why do I feel this is a trick? Once a business analyst always a business analyst.”

“First of all,” said Brian, putting his backpack down and facing Ken. “There is no such thing as ‘once a business analyst’. None of us were born business analysts nor did we plan to be business analysts throughout school. We all gravitated or were inserted into the position and the profession. Most of us came from other disciplines like systems analysis or engineering for which we were initially trained. Both Ann and I have done some turns as project manager. Many of us came out of school as engineers or with IT degrees. So it’s not that difficult to move back to one of our former positions. Besides, you have a lot of former Java and C++ programmers working on your dot-net and C# programming projects. Do we say the same thing about them? ‘Once a Java programmer always a Java programmer’?”

Ken ignored Brian and walked away. “Good luck in your new jobs elsewhere in the organization, Allen. But remember, the New Order of Agile is taking over. Two more divisions have decided to also go with agile. There won’t be any place to go soon.”

As Ken walked down the hall and Brian shouldered his backpack, Ann mused, “We were avoiding that? I wonder what he really wanted to see us about.”

“I guess I distracted him.”

“O, well, looks like today is the day. Here comes Scott, and he looks like he knows why he wants to see us.”

Scott looked troubled. He came straight at them like a shark after its prey. Brian could hear the Jaws theme playing in the background.

“I’m glad I found you,” breathed Scott. “Can we go someplace to talk,” he said conspiratorially looking over both shoulders. “How about a cup of coffee.” Brian stared at the cup of coffee in his hand and then at Ann and said, “Sure. Why not? I’m not on the clock yet anyway.”

After they got settled in a corner table of the cafeteria with their coffees, Scott leaned forward, put his glasses on the table and pushed back his longish black hair. “What do you know about Scrum Masters?”

“It’s a Zen discipline arising from the sport of Rugby in which there is both a ball and not a ball and the less you try to score the more goals you make,” offered Brian.

“My, we are quick this morning, aren’t we, and only on the first cup of coffee,” commented Ann. “We know what a Scrum Master is, Scott. What’s your problem?”

“We drafted our Scrum Masters from our developer teams. We let them volunteer because we didn’t want to impose any management selection of roles on them. These are, after all, self-organizing teams.” He paused for acknowledgment, and receiving none, continued. “Those who said they would like to be Scrum Masters were sent to Certified Scrum Master classes at our expense. So we got a number of CSMs to fill the role for the Scrum teams. Of course it was difficult. Most of the developers did not want to give up their coding to run interference for the teams. Many also felt that the Scrum Master had to indulge in politics and wanted no part of that. “

“I’m not sure I understand,” interrupted Ann. “What ‘politics’ are they concerned about?”

“One of the primary duties of the Scrum Master is ‘removing impediments to the development team’s progress’ * and another is working with the organization to promote and promulgate Scrum: ‘The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t’ And these things mean that you have to deal with the rest of the organization and that means politics.”

“Isn’t that what you and Ken are doing?” asked Brian.

“Yes. And we take seriously those edicts. And we are ‘leading and coaching the organization in its Scrum adoption’. But that is beside the point. And the point is that we don’t have enough Scrum Masters, and those we do have are not working as well as they should.”

“Didn’t they go to class and get certified?” Asked Ann.

“Yes. I said that. And the certification is two days of class followed by an exam. And it’s a fairly easy exam, too.”

“You passed it?” asked Brian. Scott didn’t pick up the sarcasm. He continued: “And they tell you what to do, but there is no real training in how to do it. And, for example, in one of my teams a senior developer is somewhat arrogant and is shredding the new, young product owner. She has left the room in tears as a result of his questions. And all he says is ‘there is no crying in software development’. And I have no experience in dealing with such things, since I am basically a developer.”

“Once a developer, always a developer”, chided Brian, only for Ann’s benefit as Scott was oblivious.

‘As I recall,” Ann tried to bring the conversation back to the point. “The Scrum Master also “Leads and coaches the organization in its Scrum adoption, causes change that increases the productivity of the Scrum Teams, coaches the development team in self-organization and cross-functionality’ *, and so forth. Those are high expectations for a developer, or anyone for that matter. Was your plan that they should be able to do these things with a two day class?”

“No. In agile it’s about learning. Each of the Scrum Masters would learn how to deal with people and learn how to play their Scrum Master roles. But they are not learning fast, and some don’t seem to be able to learn, or want to learn. And I’ve had three tell me they don’t want the position anymore. And the others on the team see that happen and they don’t want to step in. And I think we are discovering that learning soft skills is not as easy as learning a new programming language or hardware platform.”

“It seems to me as though the Scrum Master job description was written as an inducement for organizations to bring in experienced, qualified consultants. I recall one of the tenets says the Scrum Master ‘coaches the Development Team in organizational environments in which Scrum is not yet full adopted and understood,’ and ‘Helps employees and stakeholders understand and enact Scrum and empirical product development’. So why don’t you just bring on the consultants?” Asked Brian.

“No can do. I think we oversold the simplicity of the Scrum concept to Carl and Vince. And they won’t pay for consultants. They say the self-organizing teams should be able to handle it themselves. And they were willing to allow for a ramp-up time and the classes. And they expect that since the developers are able to talk directly to the business now that they should be able to do the Scrum Master roles as well. So, no consultants.”

“Yes,” agreed Brian. “It would seem contradictory to the concept of simplicity to have to bring in a high paid consultant to get things started. But what about the project managers?”

“Ken didn’t want any of them around. He wasn’t sure they could successfully drop their authority around the team. And even if they were able to stop managing and start coaching, the teams would still see them as project managers and that would make them ineffective. And, besides, Carl grabbed all the good project managers and assigned them to other projects in the organization and let the others go.”

Ann sat back and sipped her coffee. “Hmm. OK. Sounds like a problem. What do you want us to do about it? Offer suggestions?”

“Actually, I’m looking for advice, and maybe a little help. One of the aspects of business analysts I have admired is their facilitation skills: they seem to be able to enable discussions and get people involved. And, like you two guys, you seem to be able to get things done when you’re on a project, especially outside the project boundaries, working with other projects and business areas.” Brian and Ann exchanged glances, both with raised eyebrows “And I am thinking that we might be able to co-opt some business analysts into being Scrum Masters. For example, Shelly. Shelly is able to make a meeting work well. I go into a meeting and have no idea why I am there. And even when there is an agenda, all it does is list the attendees and none of us know why we are there. But a meeting with Shelly always goes well. And when any of us walk out of a meeting that she attends we know exactly why we were in the meeting and always feel that we spent our time well. And, she, like, asks questions and gets the attendees to come to conclusions, even when the meeting isn’t hers. And she seems always to be able to resolve conflict among the attendees if there is any, even among developers, and sometimes even before it starts. And I’ve seen you two do this as well.”

“Well,” replied Ann. “That could be arranged. We can send a few of our remaining available business analysts to Scrum Master classes and they can be Scrum Masters for your teams.” Ann hid her delight at having this solution drop into her lap.

Brian on the other hand had another question. “Scott, you seemed to be totally against business analysts. And now you are singing our praises. What gives?”

“I am not singing the praises of all business analysts. I’ve been in meetings with the users and your typical business analyst. And I’m there in the meeting for technical support and half the time I just sit there and daydream or wish I could open my laptop and do some coding. And the business analyst just sits there and takes notes. And whoever it is says that they are there to get the requirements and then records what the users tell them. Sometimes I have to ask questions when the users ask for something outrageous. And the BA takes everything down, you know? And it all ends up in the requirements document. And the BA tells us, ‘it’s what the customer wants.’ I mean, we could do that, and we’d spend more time asking questions And then later we find out that it’s not quite what the customer wanted because the user forgot to mention something or didn’t state it clearly. And the BA complains about the customer changing their mind or never knowing what they want. And, I mean, we could do it, you know? And, even if we did the same thing, which I doubt, at least we’d be getting the straight scoop, and getting it earlier. And the business analyst just does not add value to the exchange. Present company excepted, of course.”

“Of course.” Said both Brian and Ann together.

So it was agreed. Shelly and Juan and a couple of others would start work as Scrum Masters applying their business analyst facilitation skills to ‘facilitating Scrum events as requested or needed’ *. They could use their influence, negotiation, mediation, and conflict resolution skills to support the teams and the projects as Scrum Masters. Scott and Ann would schedule them into Certified Scrum Master classes as soon as possible. Scott agreed that both Brian and Ann would make excellent Scrum Masters, just as they might make excellent Product Owners, but they had been business analysts too long and the imprimatur of their role and their reputations in the organization would act against them in being successful as servant leaders, just as the former project managers would have run into difficulty. “And besides, there’s Ken standing in the way”, concluded Scott.

“Well, that’s it,” breathed Ann as they left the cafeteria. “Looks like we did it. That’s everyone accounted for. ”

“Except us,” said Brian hoisting his backpack on his shoulder. “However, that is all the meetings, right? Everyone who was looking for us found us.”

“Not everyone.” Ann was afraid to say the name. Just then Sandra, Verna’s Personal Assistant, rounded the corner and headed straight for them with Ken at her elbow. Ken looked like he remembered why he had been looking for them.

Was Ken in Cahoots with Verna? Had he swung Verna over to the New Order of Agile Development? Would this be the end of Rico? And do we have to hear Scott say ‘and’ one more time? And where is Cahoots, anyway? Tune in for the season finale where we find out what happens to the last two stalwart business analysts in the organization and finally meet Verna although like the Sopranos, the screen may go blank when we do.

* Quoted from Schwaber & Sutherland, “The Scrum Guide, the Definitive Guide to Scrum: the Rules of the Game”, published by Scrum.org, July 2011

Don’t forget to leave your comments below.

It’s the End of the Business Analysis World as we Know it? Part 4

Written by Steve Blais on July 2, 2013. Posted in Articles. 2 Comments on It’s the End of the Business Analysis World as we Know it? Part 4

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Chapter 4: Wherein the business analysts confront Dmitri and his curtains and provide a positive impact, and Verna phones in

Brian and Ann entered Dmitri’s office as he hung up from his phone call with Verna. He was still standing at attention behind his desk, his chair pushed back as though he had jumped to his feet involuntarily. He smiled at them and motioned them to seats in front of his mahogany desk while he pushed back the French cuffs of his shirt and sat down. Dmitri was slight of build and had longish blonde hair pulled back and parted in the middle.

Brian began the conversation. “Something is different in here than the last time I was in your office, Dmitri.”

“It’s curtains, Brian,” replied Dmitri. “I had them installed last week.”

“Not bad. I guess you are doing well, then.” Brian paused and Ann picked up the slack.

“What are the new projects that you are undertaking, Dmitri? Do you have a prioritized list with some timeframes?”

“Of course.” He pointed to a white board on the side wall where there were a number of what appeared to be user stories written in different colored markers. In front of the white board was a small round table and several chairs, “This is where I have my product planning meetings and sometimes the teams gather round for their sprint planning sessions.” He said with pride and a trace of superiority as though to say, “and you are not invited or needed.”

Brian felt somewhat annoyed if not betrayed. He had worked with Dmitri in the past. . He and Dmitri had spent hours evaluating impacts of new functions and features that Dmitri and his staff wanted to implement. Brian’s analysis of Dmitri’s proposed initiatives usually uncovered unforeseen impacts in other departments in the organization. Brian then met with the impacted constituents to mitigate or ameliorate the impact, allowing Dmitri to go ahead with this initiative. And now Dmitri preferred a white board to Brian.

Dmitri rose from his desk and walked over to the white board. He read, “as a sales person I want to have access to product line information on my mobile device, so that I can provide that information to clients on an as needed basis.”

Brian realized that Dmitri was just showing off his new toy but he just couldn’t help himself. “Are there enough sales personnel who use their mobile devices during sales calls to warrant this feature? Or are we going to have to have all of the salespeople trained on how to use the new feature?”

“That is not my problem,” replied Dmitri.”I provide the facilities; it’s up to Sales Management to make the salespeople take advantage of it. That is a management issue, and is not part of the agile development of this product.” He said dismissively and quickly turned back to the white board. “Here’s another one.” He read a user story written in red with a date marked next to it, “as a customer, I want to earn points for my purchases, so I can exchange them for additional free goods.”

Ann chimed in, “what is that feature all about?”

“That is one we’re already working on,” Dmitri answered with growing enthusiasm. “We are building a reward program for frequent buyers to increase our repeat customer percentage. We’re going to award points, based on price and volume of purchase, which can be exchanged for gifts from a catalog. It will be like the airlines’ frequent flyer programs, except we’re not going to call it ‘frequent buyer program’. We’re working on the name of the program. We will put our higher-priced or slower moving products in the premium catalog. Everyone wins. It’s a great program. We’ve been working on the supporting software for three sprints and already have user screens for point exchanges to add to the website, the programs and the database that accumulates the points for each customer, the maintenance screens for the Points Database, and the program that calculates the value of the points and the exchange. We are also doing the marketing program in an agile way as well. We have three graphics artists developing the user interface. Got a couple of copy editors writing up the copy. Everyone’s turning things around in two-week iterations.”

Dmitri’s excitement about the program was almost infectious, but both Brian and Ann saw warning flags.

Brian couldn’t stop himself again and asked: “you seem to be addressing the web-buying population. But what about the stores, the distribution channels and the retail outlets? Your user story does not limit to just web purchases. If you’re trying to attract more people to the web this might be a good program to do so, but it might enrage our distributors and retail outlets would perceive a loss in sales. If we lose our retail and distribution, we are doomed.”

Ann: “Did you consider that there will also be taxes to be paid on the gifts picked up with points? And if you order over the web, there is shipping. Will you charge the customer for that or absorb it?”

Brian: “Have you determined exactly who will be doing the maintenance and handling the customer support questions, of which there likely will be a lot? Corrine over in Customer Service has been complaining to me for a long time about how overworked her staff is. I doubt if they could take on this initiative at this time”

Ann, “Did you get together with the accounting people, to determine how this is going to be carried as a liability? Basically, you’re creating an IOU to the purchasing customer for goods you’re going to deliver in the future. Accounting won’t let you start the program until that is all sorted out.”

Dmitri seemed somewhat deflated, or at least as deflated as a marketing person can be. “The team didn’t bring the issue of liability. They only addressed how the information would be transferred from the Points Accumulation Database to a general ledger interface.”

Ann interrupted: “That’s because they talk file layouts, not accounting principles.”

Dmitri looked at Brian. “We didn’t discuss anything but the web-based interface and how it was going to be created. The team should have thought about this and brought it up during the discussion of the user story.”

“It’s not their job, Dmitri,” said Brian. “They assume that you will take care of all the business impacts. They want to know what they need to do to implement the user story. If there are other impacts, they need to see other user stories. For example, have you considered how the points are going to be awarded at the cash registers of our stores and in the retail outlets that are selling our goods? And, how about inventory? The first time an item is taken out of inventory as an award the inventory will be out of balance. Since there will be no sales order to charge against and our current order entry system requires a sales order for inventory removal.”

Dmitri slumped noticeably and went back to his desk. He flopped into his chair. “I don’t understand. We never had to worry about such things before. We just come up with programs, see them through from a marketing and sales perspective, and then we do them. Who is taking care of these ancillary issues now?”

“This apparently is the New Order of Agile, Dmitri. What did Ken say to you about this?”

“I don’t think he did. He just said the product backlog is my responsibility. We have been using the user stories successfully for a number of iterations now. Are you telling me that when we finish all the work we are doing now that we still won’t be able to put the rewards program into operation?”

“I think, Dmitri, that you will run into a lot of production problems if you tried. Not to pat our own backs, but in the past Brian and I have handled the impacts and initiated projects for other departments to accommodate the marketing initiatives. We defined the capabilities that were necessary for your initiative to be successful, and you didn’t have to worry about it.”

“But there are no business analysts in agile. Ken and Vince say so. And I certainly don’t want to meet with all the other departments and business areas. They are all so retrograde.”

“Yes,” warned Brian in a whisper. “But interruptions and impacts to operations come under Verna’s purview.” They observed a moment of silence staring down at the phone on the desk expecting it to light up with a call. The phone remained silent.

“Well,” Ann stood up and walked over to the whiteboard. She turned around with a wry smile on her face. “If the business analyst worked directly for you and was your emissary to the rest of the business he or she could identify the impacts and interfaces with the other business units and business processes. The business analyst could define what would be necessary to allow a successful implementation. The business analyst could bring back new user stories, or modified user stories that you, as product owner, could add to the product backlog in whatever priority order you desire. Then you can present the stories to the Development Team. So the business analysts aren’t really in agile, they’re not between you as product owner, and the developers.”

Brian chimed in, “not only that, but the business analyst assigned to your projects could meet with the business analysts who were still on non-agile projects and make sure that all impacts are resolved and all the projects are in synch. After all, Ken was quite adamant about the problems of still having waterfall projects in place with which his agile projects would have to interface. He wants the world to be agile and only agile, so he has no prescribed means of dealing with the non-agile teams.”

“I like it,” said Dmitri. “So you will assign at least one of your business analysts to work with me as impact analysts on all of these initiatives to make sure that all impacts to other business units and departments will be accounted for?”

“I think that can be arranged,” said Ann.

“Looks like we dodged another bullet,” breathed Brian as they walked toward the cafeteria for a cup of coffee after the meeting with Dmitri.

“Do you think we got Dmitri on our side?”

“What side is that?:

“In favor of business analysts. Realizing our value.”

“Not quite. He is using ‘business analysts’ as ‘impact analysts’. He clearly does not equate the two. He has been brainwashed by the New Order of Agile zealots.”

“Well, a business analyst by any other name is still a business analyst.”

“Let us keep that to ourselves, shall we?”

As they lined up amidst a crowd of caffeine lovers to get their coffee, Raj intercepted them, having to shout over the numerous mid-morning-break conversations around them. “Scott is looking for you. He seems desperate.”

“Wonder what that’s about?”

“Oh, and Ken is looking for you and he does not seem happy. Oh, and Verna’s secretary told me in the hall that Verna is also looking for you.” The cafeteria went silent.

Will the business analysts be able to remain business analysts in the New Order of Agile or will they have to change their names to protect the guilty or worse? What do Scott and Ken want now? Will Verna finally appear and put them out of their misery? Tune in next time when you will hear Scott say “there’s no crying in software development”, and see Brian sling his backpack over his shoulder.

Don’t forget to leave your comments below.

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.