Organizational Insights and Comments on the Agile Product Owner Role

Mike Cottmeyer (www.leadingagile.com) recently added some insightful comments on this prickly topic that I thought were worth highlighting.

I am coming to the conclusion that the Agile PO is actually three roles combined: the traditional Product Manager, the Project Manager, and the Business Analyst.…. how do we decide who is the single accountable person for the team, even when the team is small.   It seems that the Agile PO is collaboration between Product Manager, BA, and Project Manager… with maybe someone playing multiple roles. That is on a small team…. what about now at scale?  Your  PO is really a collaborative effort between a PO (and PM) structure that is likely multilevel, with each level having some combination of the three roles and maybe an enterprise architect.

This comment crisply highlights the challenge and opportunity implied by the critical and yet overloaded role of the PO in agile/Scrum. To wit:

1. The PO role is an important new construct which provides a single point of focus to the team that defines “what it is we will be building”. Eliminating the problem of conflicting inputs from multiple sources provides a) efficiency leverage for the team, b) enhanced empowerment via team-based control of  product conceptual integrity and c) a clear and unambiguous set of priorities
2. However, it also creates many problems in the process. After all, how would we expect architects, project managers, business analysts, product managers, etc. to respond to the new rule: “you no longer tell the team what to build or the details of how to implement it, that all must go through the Product owner from now on”.

Wouldn’t we expect this to cause some serious problems? Especially in the larger enterprise context where the roles (and titles) are well established, empowered, likely quite capable, and are codified in the existing HR/career development ladder? No wonder the PO challenge is so great!

However, having said all that, we should make no mistake about the fact that implementing the PO role (largely as defined in Scrum) it is the right challenge for the agile enterprise and it must be addressed for agile success.

You can see more of Mike’s thoughts on this topic at www.leadingagile.com. I’ve added his blog to my blog roll as well.

Agile Journal Article Series: The Product Owner in the Agile Enterprise

For those following this blog series, some of this content has been repurposed for a three part series in the Agile Journal. Part I- On Agile Product Managers and Product Owners: A Scalable, Nuanced Approach, has just been published. The content mostly follows what is being published here, but its’ stitched together for a little easier reading and better digestibility. And it’s more portable, too, as you can download it in PDF form.

For those who hadn’t been following the Agile Journal, I’d strongly recommend it as it has diverse and refreshing content in every edition.

My Agile Journal series and this blog series on this topic will continue in parallel, as they serve slightly different purposes. I’ll keep you posted on upcoming journal articles based on this series. In the meantime, this blog series will continue and the next post here will be “Responsibilities of the Product Owner in the Agile Enterprise.” This post is deeper and more specific than the prior posts in this series, and will hopefully be more actionable for the enterprise Product Owner too. It’s out for comments right now so I should have it posted sometime next week.

Agile Product Owner and Agile Product Manager in the Enterprise Part 3: Skills and Attributes of the Product Owner

Note: This is a part 3 of continuing series on the critical Product Owner’s role within the agile software enterprise. My primary collaborators on this series are Mauricio Zamora of CSG Systems, and Jennifer Fawcett of www.agileproductowner.com. This series, in turn, is in part an elaboration of the broader Agile Enterprise Big Picture series.

Recap of the Dual Roles

In Part 1 & Part 2, we described the critical nature of the role in achieving enterprise agility. We also described how, in the enterprise at least, the responsibilities of the agile Product Owner (as originally and primarily defined by Scrum) is more likely a set of responsibilities that are shared between a significant number of agile Product Owners (APO) and a smaller number of agile Product Managers (APM). Specifically, we described a dual set of roles as follows:

Agile Product Manager	Agile Product Owner
Market/ customer facing	Product/technology facing
Collocated & reports to marketing/business (typically)	Collocated & reports to development/technology (typically)
Focuses on market segments, portfolio, positioning and ROI	Focuses on product and implementation technology
Collaborates with Product Owners	Collaborates with Product Managers
Owns the Vision	Owns the implementation
Drives the Release	Drives the Iteration

This conclusion isn’t particularly startling when you look at some basic enterprise facts:

1. It can take a substantial number of agile teams (3-5-10 or more) to deliver meaningful end user value, for even a single new feature in a large application
2. It can take an even larger number of teams (10-20-100 or more) to deliver a release to the market

So with respect to Owning the Vision you obviously can’t have 3-5-10 Product Owners each trying to deliver their individual view of the vision of the feature to the market. Therefore the overall vision for the feature must rest in the hands of someone who has the skills, knowledge time and inclination to work directly with customers to define and validate the feature vision. In most independent software vendors (ISV), this typically rests in the hands of the Product Manager. (Note: In the IT shop, this role is often fulfilled by someone with the title of “Business Owner” or “Project Manager”. In the embedded systems world, the role may often be fulfilled by someone with the title of Product Manager, or Project or Program Manager).

With respect to Drives the Release, the problem is compounded because it can take the collaborative efforts of 10-20-100 agile project teams to deliver a release. Each Product Owner/Project Team contributes their feature, sub-feature or component, but the release itself must be under the vision and governance of a broader authority, most typically the Product Managers/Business owners who are, in turn, working with those who have responsibility for the enterprise portfolio.

So we have concluded that this separation of concerns can bring additional focus to both the vision and the implementation, and the role separation (APO and APM) can be a fairly natural fit for the larger enterprise.

Skills and Attributes of the Enterprise Product Owner

As we have said, this is a critical role in achieving enterprise agility, so the transitioning enterprise will need to find people to fill this role. In the larger enterprise, this can involve the repurposing or placement of as many as 10-20-100 individuals (one PO for every one or 2 agile teams). The primary responsibility of the PO role is to work daily with the team to define the specifics of the intended behaviors of the system and further, to help the team deliver on those expectations. In order to be effective in their role, the enterprise should look for people with four key skills and attributes:

1. Ability to communicate—the Product Owner is the “glue chip” that binds the Product Management function tightly to the development team. Doing so requires the best possible communication skills as the Product Owner translates, via the user story metaphor, user and business objectives into details suitable for implementation. Moreover, the Product Owner will almost certainly be involved in customer demos, sales support and the like, so some customer-friendly skills will enhance performance in this role.
2. Good business sense—Agile’s insane focus on value delivery also demands that Product Owners should have working knowledge of the business domain. In this way, the PO can better understand and define user stories that deliver real value to the end users and establish priorities and tradeoffs for system functionality and performance. If that is not practical, the PO must at least be inclined towards the user and business domain and in general, be a quick study who has demonstrated people skills and general business knowledge.
3. Technical foundation—effective scope triage requires the constant evaluation of technical, functional, performance and user-value tradeoffs. This, in turn, requires a reasonable degree of technical competence as well as an understanding of how it is that software is actually developed and tested. In addition, as continuous refactoring is integral to agile, prioritizing refactors and defects is important and the PO must be able to work closely with the team to assess quality and schedule impact.
4. Trust—Since the primary responsibility for prioritizing and managing the backlog (i.e. what will and will not be done) falls to this role, the most essential attribute of the Product Owner is trust. The teams have to trust the Product Owner to help them build the right thing; make the hard calls on scope triage and to defend their interest in quality and functionality. The Product Managers have to trust the Product Owner to faithfully represent their features and feature priorities to the development community.

Looking Ahead

Finding people with these skills and interests and providing them with sufficient mentoring or training is the responsibility of the management team driving the enterprise transition. To further assist in this challenge, I’ll describe the specific responsibilities and activities of the agile Product Owner in the next post. In a later post, I’ll describe some case study vignettes of how some real world enterprises successfully addressed the challenge of finding the right number and right kinds of people to successfully implement this role.

Agile Product Owner and Agile Product Manager in the Enterprise: Part 2- A Dual Role Approach

Note: This is part of a new and continuing series which is collected under the Product Owner/Product Manager category.

In the last post, Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Managers , I described how both of these roles and titles are likely to exist in the agile enterprise. In an attempt to avoid this apparent complexity, I described two alternate, but ineffective plans A and B.

• Plan A) – The Product Manager will assume the role of the Product Owner and add Responsibility 2) (i.e. The Scrum Product Owner is a member of the team and works daily with developers and testers to help the team meet its Sprint objectives) to their existing responsibilities.
• Plan B) – The Product Owners on the new agile teams will now assume some or all of the prior role and responsibilities of the Product Managers.

Experience has shown that neither of these paths is particularly effective and a more nuanced, Plan C approach, is required.

Plan C – The Dual Role Approach

With Plan C), a number of enterprises have taken a more refined approach which supports dual roles of Agile Product Manager and Agile Product Owner as follows:

• The more market(/customer) facing Product Managers continue in their role, keeping most of their existing responsibilities. However, they also evolve a far more agile set of practices, including taking on a tighter relationship with the development team (in large part via a “fat dotted line relationship” to the Agile Product Owner) and engaging more directly in release planning content and validation.
  
• The product (/technology) facing Product Owner role is assumed by either; a) more technically inclined Product Managers; and b) development team members and/or others who are interested and best suited for Responsibility 2. (Note: Since, in the enterprise, there can be a number of them (10-20-50) required; where these people come from is the subject of an upcoming post). The team members in this new role assume the fairly well defined agile PO responsibilities but also take on a tighter relationship with Product Management (the fat dotted line we described above). A side benefit of this approach is that it empowers the development team to take additional control of their destiny. It can also provide a new career path for those team members who would like to “grab hold of the steering wheel” in the increasingly agile enterprise.

The Name Game – Experimenting with Roles and Titles

In the prospective agile enterprise, it doesn’t usually take very long for the loaded role/title and implied responsibilities of a new “Product Owner”  to portent a major crisis. Indeed, it can even be such a sensitive matter that the agile adoption can be seriously endangered by the potential conflict in role, title and responsibilities, so serious caution is warranted!

One way to address this problem is by changing the title of the Product Owner role. In a couple of instances, for example, the role of agile Product Owner was assumed by the existing role and title of the business analyst, who already had most of those responsibilities and had even already been relocated to be collocated with the newly formed agile teams. In other cases, the historical title of requirements analyst was assigned to the role. In yet another example, (see BMC Case study), a new title/role of requirements architect was invented, which helped clarify the role and helped avoid conflict with existing titles role and responsibilities. Of course, none of these titles fit every context perfectly and in changing the title of Product Owner is likely to be more trouble than it’s worth, since it isn’t reflected in agile literature or in the standard trainings available.

Even then, some confusion can result. For example, Keith Black, who as VP Product Development at TradeStation Technologies is driving a comprehensive agile initiative, recently  described the problem to me this way:

“we’ve clearly found that the role of PO is NOT a PM. In fact, this has led to difficulty in us even describing the position in help wanted ads. If you run an ad for Product Owner you get responses from people that want to be a Business Owner. If you run the ad for PM’s you get traditional PM’s that are not technical. We could call the role “Analyst” or “Requirements Analyst”, but that attracts more of a Systems Analyst profile. And given the fact that there’s a void in the PO role in the Scrum world, it creates a situation where no-one is out there who understands what the title means.”

So for many enterprises, the role/title of Product Manager continues and the new role of agile Product Owner is adopted, but each has a refined set of responsibilities as we have described here.

Dual Roles in the Big Picture

The dual role approach isn’t that new to this blog and has already been indicated and described in the Agile Enterprise Big Picture series and graphic as this figure indicates.

  

Agile Product Owner and Agile Product Manager in the Big Picture

While the details of the Big Picture are outside the scope of this post, (for this, see Big Picture category) a few relevant highlights include:

• Product Managers tend to operate at the Program Level, providing vision that drives a significant number (5-10-20 and more) of agile teams. Their “currency” of system behavioral description is most typically Features.
• Product Owners live at work with the teams at the Project level. They work with only one (two is also fairly common) teams typically. Their “currency “of system behavioral description is User Stories.

Dual Roles: Differentiated Responsibilities

Within the enterprise context, we often see the two roles align as follows:

Agile Product Manager	Agile Product Owner
Market/Customer Facing	Product/Technology Facing
Collocated & Reports to Marketing/Business	Collocated and Reports to Development/Technology
Focuses on market segments, portfolio, positioning, ROI	Focuses on Product and Implementation Technology
Collaborates with Product Owner	Collaborates with Product Manager
Owns the Vision	Owns the Implementation
Drives the Release	Drives the Iteration

Summary

In these first two posts in this series, I’ve describe a more nuanced, dual role approach to the agile  Product Owner/Product Manager functions in the enterprise setting. In the next few posts, I intend to describe:

• The key attributes and day to day responsibilities of the Agile Product Owner
• Some tips for building a successful collaboration across this new APO and APM team of teams.
• How and where real agile enterprises go about finding the right people to fill these roles

And then eventually,

• How the Product Manager’s responsibilities also need to evolve in the agile enterprise

And probably some more stuff by the time I get there.

Agile Product Owner and Agile Product Manager in the Enterprise: Part 1- On Product Owners AND Product Managers

This post starts a new series on the role of the Agile Product Owner and Agile Product Manager in the Enterprise context. While I, and others, have certainly opined on this topic in this series in the past, the continuing interest, enterprise challenge and controversy (this topic gets more blog hits than any other category on this blog) around these role descriptions in the increasingly agile, larger enterprise compels me to put my thoughts forward in a more structured manner. To this end, I’m starting this new series of posts to elaborate on my experiences in the context of some of the largest software enterprises transitioning to agile methods. Unless I get distracted for some reason, I also intend to turn this series into a more readable whitepaper form longer term. In the meantime, I’ll be spewing it out in post-size chunks. This is the first chunk.

Introduction

Recently, I’ve had the opportunity to assess progress in a number of large scale agile transformations, touching hundreds and in some cases, thousands, of new agile practitioners. Most typically, these involve comprehensive Scrum training for team members along with training for some number (10-100s) of ScrumMasters. Less typically, they include training for agile product owners, some XP-like technical practices (peer review , pair programming experimentation, TDD pilots, etc) and such enterprise extensions (lean requirements, agile release train, etc.) as have been brought to these companies by enterprise agilists such as myself.

Happily, I can report three common and positive findings:

• Productivity is going up
• Time to deliver new features to the market is going down
• Morale is higher, often times MUCH higher

Not one entity I’ve encountered has any interest in returning to their former practices. So all in all, these enterprises efforts to date are an emerging success and many are now redoubling their efforts to achieve the next level of productivity and quality possible with agile methods. To achieve this, we often assess current results and accomplishments – strengths and weaknesses – and then make specific recommendations for ongoing improvement.

During this process, it strikes me that the critical role of the agile Product Owner is often near the top of the list – though unfortunately it appears most often in the “areas we need to improve” rather than on the other side of the ledger! This finding causes me to reflect on the bigger picture of the agile movement as it “crosses the chasm” to the enterprise and to record my thoughts about the nature of the Product Owner role in the enterprise, along with some specific guidance and recommendations for improving these practices.

In this post, I’ll describe why I believe software vendors need to adopt a nuanced, rather than off-the-shelf, approach to this role; one which empowers both agile Product Managers and agile Product Owners to drive the enterprise to meet its objectives.

The Product Owner in the Enterprise Context

First, it is important to note that I write this whitepaper from my own experiences in the larger enterprise context. While I have also been involved in a number of highly agile, smaller projects, it is in the context of the really large enterprise that the challenge is greatest. It is there that some of the standard, off-the-shelf Product Owner practices and trainings break down, and the otherwise successful oversimplifications that drive agile success (“what is the simplest thing that can possible work”) simply do not scale to the enterprises challenge. The principles remain the same, but the practices must be extended.

The Product Owner in Scrum

It is to Scrum that we owe the nifty invention of the role of the Product Owner. As recently defined by Schwaber [The Enterprise and Scrum], the Scrum Product Owner

“is responsible for representing the interests of everyone with a stake in the resulting project …achieves initial and ongoing funding by creating the initial requirements, return on investment objectives and release plans.”

But the Product Owner’s responsibilities don’t end there. At the same time, the Product Owner is a resident of the ideal Scrum team as Figure 1 (adapted from a Certified Scrum Course) illustrates.

Ideal Scrum Team?

It can be implied from the figure and as follows in support of Agile Manifesto Principle #4 – (Business people and developers must work together daily throughout the project), the Product Owner is ideally collocated with the team and participates daily with the team and its activities.

We also note the “7 +/- 2 members” recommendation for the ideal team.

In an attempt to achieve theoretically better  organizational efficiencies in the enterprise, I’ve tried larger agile teams  and frankly, it simply doesn’t work! So in my experience this “7 +/- 2” number is sacrosanct and stands as a respected canon within the enterprise as well as in a smaller company setting. Of course, the impact of this rule is that one of the major challenges in the enterprise is that there can be a very large number (20-50-100 and more!) of such teams required to deliver a large, cooperative application. But such is generally the problem of scale.

Further, as taught and commonly practiced, the Scrum Product Owner has additional, tactical activities that directly contribute to the team’s success. These include:

• Setting objectives for the Sprint (iteration)
• Prioritizing and maintaining the backlog
• Participating in the Iteration planning meeting
• Elaborating stories on a just in time basis with the team
• Accepting stories into the baseline
• Accepting the Iteration
• Driving release planning

Given this set of responsibilities, it is clear why the Product Owner is such a critical role in the agile project. However, the scope of the problem in the enterprise is daunting because we have just identified 20-50-100 new roles that have to be filled in order to execute agile successfully. Given this context, it should come as no surprise that “enhance capabilities in the critical Product Owner role” often makes it to near the top of the enterprises ongoing improvement recommendation list!

The Conundrum – Why the Enterprise Product Manager is Likely NOT the Agile Product Owner

In summary, there are two primary responsibilities that can be derived from the above:

Responsibility 1 – The Scrum Product Owner sets the vision, product objectives and manages to ROI

Responsibility 2 – The Scrum Product Owner is a member of the team and works daily with developers and testers to help the team meet its Sprint objectives.

However, when agile is introduced into a true enterprise context, (most typically through Scrum team training as we described earlier) there often occurs a role and paradigm mismatch between the Scrum teachings and the existing organizations structure. Specially, the mature software product enterprise is certain to already employ Product Managers who have the requisite skills, training, and existing responsibilities for Responsibility 1, above.

They work directly with customers; their responsibilities include product definition and their reward system contains an ROI element. They are trained professionals; they know what they are doing; they have extensive domain knowledge; they already work there and they have influence and authority.

This creates a conundrum which is being addressed from both the Scrum side (though standard trainings and the relatively new “Scrum Certified Product Owner Course”) and those who represent the existing professional practices of Product Management within the ISV (Independent Software Vendor) community. In one fairly pointed article, for example, Rich Mironov of Enthyosis comments:

“Product Managers are responsible for the overall market success of their products, not just delivery of software. In the Agile world, a new title is emerging—the Product Owner—which covers a small subset of the Product Management role. While this makes sense for internal IT groups that have traditionally gone without Product Management, …..agile product companies need full-fledged Product Managers to drive strategic activities and manage organizational/external participation.”

Plan A and Plan B

If we approach the enterprise in a naïve way, we might think the conundrum will be handled one of two ways:

Plan A) – The Product Manager will assume the role of the Product Owner and add responsibility 2) to their existing responsibilities. In practice, however, this plan does not work very well:

• It doesn’t scale. There may be 30-50, or even hundreds of development teams requiring this intense tactical support and there are typically not nearly enough Product Managers to go around. (I saw one case, where, prior to agile 400 developers were supported by six Product Managers).
• Product Managers may be ill suited, ill inclined and downright uninterested in these responsibilities. After all, if Product Managers wanted to live with development, they probably wouldn’t have picked their chosen path! (For those with a thicker skin, see the footnote (1) below from the Cranky Product Manager blog below. But Remember, it does say “cranky”)
• Effective Product Managers often have insufficient technical depth and inclination to add significant value to the team’s highly technical language, activities and responsibilities.

Plan B) – The Product Owners on the agile teams will now assume some or all of the prior role and responsibilities of the Product Managers. This plan doesn’t work well either:

• Why would existing Product Managers want to give up any of their influence, authority and contribution to these new agile types?
• Where would these new Product Owners come from? Hire them from outside, where they are likely to have less domain expertise than the existing Product Managers?

Experience has shown that neither of these paths is particularly effective and a more nuanced, Plan C approach, is required. But as this post is already way too long, that will have to wait for the next post, which I hope to be able to push later this week.

======================================

Footnote 1: ” (some) argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day. Uh, no way.  Not gonna happen. Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away. ” Cranky Product Manager blog.

Use Cases in the Agile Enterprise Requirements Information Model

Note: this is the conclusion (for the moment at least) of an extended series on a Lean and Scalable Agile Enterprise Requirements Information Model, which can be found in the Agile Requirements blog category.

In an earlier post “What, No Use Cases in the Requirement Information Model?”, I noted the following.

“Regarding use cases, I haven’t yet made them citizens in the agile requirements meta-model. However, when building systems of scale, there is no tool quite as powerful as a use case for exploring the interactions amongst users (and other actors), the system, and subsystems of the solution. Moreover, the use-case technique is the best way I know to help identify all the alternate scenarios that trip us when it comes to system level quality and readiness…I am also reminded of the fact that use cases have been well applied in other agile models ……. ( see post.) so I came to the conclusion that not including them in the agile model was myopic of me. Therefore, I’m going to introduce use cases as an optional element of the agile requirements information model in an upcoming post.”

This is that post.

Benefits of Use Cases in Agile Development

While use cases are not a replacement for the user story in agile development, they can be of tremendous benefit in elaborating, analyzing and better understanding the intended behavior of complex systems. For example in a prior post, Jennifer Fawcett (agileproductowner.com) described benefits of use cases in the context of agile development, highlighting : ( my paraphrasing)

“use cases are a statement of understanding whereby developers can first agree, and then remember, (how it was that this complex system was supposed to work), including main success scenarios and alternate success scenarios, as well as variations and open issues.”

Use Case Basics

For anyone not familiar with use cases, there are dozens of good books on the topic, including Cockburn’s Writing Effective Use Cases (currently the top ranked book I could find on Amazon with agile and use cases) and Leffingwell and Widrig’s Managing Software Requirements: A Use Case Approach .

But for the uninitiated, I offer the following summary:

A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor.

Where:

• Sequences of actions —describes a set of steps; i.e. functions performed by the system that produce a result.
  
• System performs—the system works on behalf of the actor. It does what it does when the actor (or other system or device) tells it to.
• An observable result of value—the result of this activity is some benefit to the actor. (Otherwise, why bother?)
• A particular actor—someone (user) or something (system or device) that interacts with the system

Use cases also have a well defined canonical form, which is broader, deeper and allows for a more complex description of the systems interactions that does the user story (see my user story description in this post). The standard use case form appears below:

The description is a short summary of the use case (not unlike the “Card” part of the user story). The flow of events is the pithy part and it itemizes the series of actions between the actor and the system. Pre- and post-conditions provide state information that is relevant at the time the use case is executed. (Example: “the URL data server has to be initialized before this use case is executed”) that further describe the expected behavior of the system under those conditions.

It is the alternate flows (or alternate scenarios) that provide much of value to the agile system builder. For it is here where we are forced to think through all the “what ifs” that might affect our user story. For example: “what happens if the URL server is initialized, but it returns a null result” or ” if my phone battery is low—and I’m uploading a big picture —and an incoming call comes in—what happens then?” Understanding all the alternate flows of a use case fleshes out the various (usually less likely) scenarios that the system must handle with grace in order to assure system level reliability and quality.

Use Cases, User Stories and Incremental Development

As we’ve indicated, use cases are not a substitute for user stories and you don’t have to use them at all. However, if your system is complex and is composed of subsystems (what complex system isn’t?) then use cases provide a mechanism to help force the developers into thinking about all the possible paths through the system that the users may encounter as well as the various states (pre- and post-conditions) that must be addressed.

In turn, this helps the team understand where user stories of various types are likely to be needed. These appear as “story pockets” in the figure below:

Use Cases Traversing a System of Systems

In addition, once understood, the use cases themselves can drive agile and incremental development, one story at a time, as Per Kroll’s graphic below illustrates.

Sequencing User Stories in Iterations

In this graphic, one can see how user stories get implemented in bite sized (iteration sized) chunks over time (story 1 – iteration 1, story 2&3-iteration 2, etc). To the agile developer or product owner, this can be extremely helpful in understanding the larger system picture that can be easily lost when the teams focus on “one user story at a time.”

Use Cases in the Information Model

I apologize if I’ve belabored use case basics too long. But here’s what we’ve learned.

1. Use cases are optional but can add tremendous value to understanding behavior when the system is complex
2. Use cases help teams understand all the “what if” scenarios that ultimately affect system quality
3. Use cases can be used to understand where new stories are likely to be found
   and,
4. Use cases can provide a logical way to sequence value delivery in big systems, story by story

In other words, use cases are an optional technique which we can use to better elaborate desired system behaviors.

In our agile requirements model, system behavior is expressed as Backlog Items, so let’s put use cases there, on the advanced form of our agile requirements information model, like this:

Summary and Use Case Tips

In this post, we’ve elevated use cases to become first class citizens of the agile enterprise requirements information model. They are a tool, like all tools, that work best in certain situations. In the case of use cases, they work best when the system is complex, and is composed of subsystems and components that must cooperate to deliver the larger value for the user.

If you decide to use them, keep these tips in mind.

• Keep them lightweight- no design details, GUI specs, etc.
• Don’t treat them like fixed requirements. Like user stories, they are merely statements of intent
• Don’t worry about maintaining them, they are primarily thinking tools
• Model informally –whiteboards, lightweight use case diagrams etc. –but code formally with your disciplined XP-like programming practices.

As an agilist, remember you don’t have to use them, but no one can tell you not to use them either and you’ll likely be quite happy if you do!