Enterprise Agility – The Big Picture (13 continued): Estimating Epics

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing post (see the Big Picture Category on this blog ) we have been gradually working our way from the bottom (stories, iterations and the like) towards the top to where the enterprise vision originates. In the last post Portfolio and Vision, we briefly described the Epics that drive so much of the behavior of the agile teams at Level 1 and 2. In this post, we’ll talk about Epic estimation.

Big Picture 13 (continued) - Estimating Epics

Everything Starts with the User Story

Before we discuss estimating Epics, however, we must return to Level 1where the teams do their work. In an earlier post, we discussed the User Story.  This is the artifact used by agile teams to communicate the basic intent of the behavior of the system, heavily weighted towards descriptions which clearly deliver value to the user. User stories are captured and maintained in a team’s Backlog, where they are prioritized, estimated and held until they are to be implemented. Estimating user stories is a team skill that all agile teams must master. The aggregate amount of story points that a team can deliver in the course of the iteration is the team’s velocity, and every agile team has one and maintains it routinely. Velocity represents the amount of user value (number of story points) that a team can deliver over any particular time box. Story points can be measured in the abstract (story points) or as Ideal Developer Days (IDDs), with the abstract measure being the most common.

To learn how to estimate points in the abstract, teams are taught relative estimating, often with the simple exercise below:

Exercise: Assign “dog points” to each of the following types of dog to compare their “bigness”: Labrador Retriever, Dachshund, Great Dane, Terrier, German Shepherd, Poodle, St. Bernard, Bulldog.

With this exercise, teams learn how to assign a “relative bigness” to each dog (or story) without debate or concern for the actual units of measure. Then they use that scale to estimate their upcoming stories and after a few iterations, they know their initial velocity (story points per iteration) by counting the points for all completed stories. When teams change size, or vacations or holidays occur, they simple adjust the expected velocity in each iteration and plan for a greater or lesser number of stories as indicated.

Estimating Delivery of Features or Epics

At the Feature or Epic level, our estimating model can be the same and it builds on the basic agile estimating team skill. We simply estimate these bigger items relative to each other and maintain the relative estimates in the Release or Portfolio Backlog. However, while that part is relatively straightforward (but admittedly it is not so straightforward to compare unlike things to each other), even relative sizing gives us no idea when a team can possibly ship what.

For this next step, we are dependent on the Big Picture’s model of expressing system behavior in terms of the parent-child relationship implied by Epics, Features, and Stories:

>> Epics cause Features to exist; (features are “children” of the epics that spawned them)

>> Features cause Stories to exist; (stories are children of the features that spawned them)

>> Stories are the native implementation unit and are also used to measure Velocity

All that is well and good but it still doesn’t tell us anything about when we can deliver what to whom. For this we need some tracking information which allows us to translate Epics into story points. Fortunately, competent agile project management tools (every agile enterprise will likely have one) support this hierarchical model and will have captured historical story point data for earlier Features and Epics. Given an understanding of what percentage of the team’s time we are willing to devote to the new item, we can use historical data  to predict how long it will take to deliver a new Epic. (Example: Epic A was implemented in about 1,000 story points and took X months; Epic B is a little bigger, therefore B will take a little longer).

The Estimated Cost of an Epic can also be Derived

This provides a rough estimate of the time it might take to deliver an Epic based on teams (and teams of teams) actual velocity. It still doesn’t give us any notion of cost. While the teams themselves may not have a one-for-one translation of a cost of a story point, at the portfolio level it is fairly straightforward to calculate one. Simply, look at the burdened cost for any timebox for the set of teams most likely to implement the new Epic and divide that by the number of story points they achieved in the same unit of time. This gives an estimate of the cost per story point for the subject teams in that domain. So if a story point costs, for example, $1,000, then more story points cost more.

A Big Note of Caution

I suspect that you’ve already applied caution enough with this imprecise, yet effective agile estimating model. However, one additional and critical factor is the assumption that all a team’s story points can be dedicated to a new initiative. That is rarely the case as most teams run from 20-50% of their total capacity supporting the existing product with necessary features that are “below the radar” of the portfolio level, as well as resolving defects, performing research spikes, refactoring and other work items that may not contribute so immediately to new user value. So in applying this model, one must be aware of how teams measure their velocity and base the time estimate (but not the cost estimate) on the velocity which is actually available to be used for new Epics.

That’s it for this post. The next post will likely be a miniseries (a post or two or three) on that last big box to the left, the Agile Portfolio.

Enterprise Agility-The Big Picture (9): The Agile Product Manager

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams, Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release , Vision and Release Backlog and The Roadmap. In this post, we’ll discuss the Agile Product Manager, [callout 9] below.

Big Picture 9 - Agile Product Manager

I’ve blogged off and on the “agile product manager vs. agile product owner” roles over the last few months so this is not a new topic and I won’t repeat it all here. Many of these posts are categorized under the Product owner/Product Manager category on this blog. We have also touched on the Product Manager in the Big Picture post on the Agile Product Owner and the follow on post. In addition, I described some of the basic Product Manager responsibilities in this article a few years back.

Based on blog hits and search criteria, this topic is pretty relevant right now so it’s a good time to elaborate further on the responsibilities of this role within the context of the Big Picture.

Product Manager/Business Owner/Business Analyst?

Throughout this series, I’ve used the term “Product Manager” instead of Business Owner or Business Analyst, even though those terms may be more familiar in some enterprises. Regardless of organizational structure or title, an effective business owner must exist and they must drive the vision either directly, or through the product management/business analyst organization. An effective Business Owner/Product Manager should exist for each major domain of the solution or the agile teams will be filling in the gaps, possibly with mixed results, depending on their expertise in the various domains. For consistency, we’ll continue to use the term “Product Manager” from here forward, but the reader may wish to translate that into the terms of their enterprise.

Responsibilities of the Product Manager

Agile or not, the Product Manager must fulfill the following responsibilities:

1. Stay abreast of the latest industry trends
2. Understand the changing needs of the market and the customer base
3. Maintain a solid understanding of the current solution

Using this data, the Product Manager’s primary responsibility is to then

1. Articulate a clear direction for addressing gaps and opportunities
   

The Agile Product Manager

Like most every other role in the software enterprise, the Product Manager’s role evolves as the company transitions to agile development methods. The first decision is whether or not the Product Manager assumes the role of the agile Product Owner and thereby takes on the additional responsibilities for iteration planning, story elaboration and prioritization, demo and acceptance. As we’ve noted before, that is probably not practical within the enterprise (see Responsibilities of the Agile Product Owner vs. Enterprise Product Manager and Role of the Product manager ). The differing responsibilities for the two roles are then as highlighted in the following table.

Responsibilities: Agile Product Manager and Agile Product Owner

Agile Product Manager in the Big Picture

As can be seen in the table and as is implied in the Big Picture, we see that the Product Manager owns the Vision and Release (Feature) Backlog and as its implementation in the Release and the
Roadmap. The Product Owner is a charter member of the Agile Team, and owns the User Stories and Iteration (story) Backlog and the implementation via Iterations. Working together, the Product Manager and Product Owner steer the agile enterprise.

To fulfill these responsibilities, the Agile Product Manager:

Owns the Vision – in collaboration with the business owners and the Product Owners, the Product Manager sets the Vision and the prioritized feature set which further describe how the Vision may be fulfilled in the implementation.

Drives the Release Objectives and Priorities through Release Planning – The Product Manager plays a key role in the Release Planning process as well, whereby they have routine and periodic, face-to-face opportunities to communicate objectives directly to the agile teams.

Updates and Maintains the Roadmap – One result of this process is the Product Roadmap, which serves as the plan of record for coupling the Vision to Implementation Timelines. The Product Manager uses the Roadmap to communicate the Product Managers “big picture” to the stakeholders inside and outside the enterprise.

That’s it for the Agile Product Manager. In the next post in the Big Picture Series, we’ll get back to the execution model and describe the role that the Release Management Team plays in helping assure the successful implementation of all that Vision.

Note: A Special thanks to Mauricio Zamora of CSG systems, who contributed some content and insight for this post.

Enterprise Agility-The Big Picture (8): The Roadmap

Note: In the post Enterprise Agility: The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In prior posts, we’ve discussed Teams,  Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release and Vision and Release Backlog. In this post, we’ll discuss the Roadmap, [callout 8] below.

The Big Picture 8-The Roadmap

For anyone following this series closely, you may have noticed a subtle shift at some point when the Roadmap icon (8) magically appeared behind the Vision (7). While I’ve been trying not to overload the Big Picture with unnecessary detail, it became clear during my explanations that the Roadmap is integral to the Big Picture and you can’t effectively explain enterprise agility without describing this key element.

When we described the Vision in the last blog post, it was presented as time-independent; the Vision is intended to provide a sense of the objectives of the product or system without any binding to time. This is appropriate as the objective is to communicate the gestalt of “what this thing is we are about to build” and overloading with timelines will likely derail the discussion of the “what”.

However, in order to set priorities and plan for implementation, we need an additional perspective that enhances the understanding. This is the purpose of the Roadmap. The Roadmap is not a particularly complicated thing, nor is the mechanical maintenance of it difficult. For example, a typical Roadmap might be communicated in a single graphic as follows:

Sample Product Roadmap

The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set. While it is a simple thing mechanically to represent the Roadmap, figuring out the content is another matter entirely. The topic of what the team plans to ship and when can be a deep, fascinating and occasionally contentious topic in agile and we can’t cover it all here. However, the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process. Fortunately, we covered Release Planning fairly extensively in the Release Planning blog series as well as in the Enterprise Agility Big Picture (6) The Release so there is some Roadmap guidance there for those who follow this Big Picture model.

But before you do all that clicking and reading, here are some summary guidelines for the role of the Roadmap in the context of the Pig Picture:

• The Roadmap is an output, rather than an input to the Release Planning Process
• The next release may be Internal or External. In either case, the dates and themes for the next release are fixed. The features are prioritized and variable.
• The Roadmap is a “plan of record” and is subject to change as development facts and customer needs change
• The teams generally commit to only the features in the next upcoming release. Releases beyond the next represent only the team’s current best estimate.

And perhaps the most important guidance is this:

• Even within the next upcoming release and even though the team has committed to the objectives of the release, the feature set cannot be guaranteed. If it were, then you would have fixed scope-fixed time-fixed resources for an extended time period and that fails the agile acid test. However, it is a reasonable expectation that a team that has committed to the release will:
  1) meet the date
  2) meet the theme or objective, and
  3) deliver most of the features, and certainly the highest priority ones with the requisite quality.

  Doing anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!

That’s it for the Roadmap in the Big Picture. We’ll touch upon it again in our next post, the Agile Product Manager.

Ideal Training for Enterprise-Scale Agility?

Pete Behrens (www.trailridgeconsulting.com) and I were formulating a training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach. Based on my experiences at BMC Software and his experiences at Salesforce.com, as well as some of our larger, ongoing clients, we had a chance to reflect on what we would recommend as the “right” amount of training to ensure success. We concluded that for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal. The summary of our training recommendations by role is seen in the figure below:

With this model, all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise) which we recommend as the minimum requirement, with an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master. All other executives and managers are invited to attend an overview course on scaling software agility.

Each of these courses is described in summary form below.

Agile for Teams –Essential, team-based training in a two day workshop setting that introduces the philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum). This is an interactive workshop with a specific project context producing a draft release plan and first iteration (sprint) plan. Training should also include those enterprise extensions applicable to the company’s context.

Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.

Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.

The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.

Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.

Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders.

• Part I – overview of agility highlighting lessons learned from the most common and effective agile methods
• Part II – seven team best practices of agility that natively scale to the enterprise level
• Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility

I’m curious to hear whether others think this is too much or too little and what other patterns trainers have found to be effective?