Measuring Business Value Is Not The Points

I facilitated a version of the Product Owner Value Game at IBADD2016 . Dojo Breddels and Paul Kuijten created the Product Owner Value game to use during their coaching efforts to help people become more value driven. They presented the game at Agile2015 where they shared the rules of the game and provided some thoughts on how to facilitate discussions result from playing the game.

IBADD2016 is the second time I facilitated the game, and I primarily use it to try and get across two main learning objectives:

  • How to become more value driven
  • How to Maximize Outcome with Minimum Output

Since I had an hour and 45 minute workshop time slot, I decided to extend the retrospective that occurs after we finished playing the game. To aid the retrospective, I posted three questions and asked the participants to put their thoughts on sticky notes for these questions. The three questions were:

  • What did you learn?
  • What still puzzles you?
  • How can you apply this at your job on Monday?

I committed to the attendees that I would tackle the items listed in What still puzzles you? in either blog posts, or with pointers to other materials. This post addresses several of the questions that all centered around the same topic – business value and measuring it.

If you would like to see a copy of the materials I used for the game, and the outcomes from the retrospective, join my mailing list . I will send you copies, followed by the occasional update on new materials I post related to discovering the right things to deliver and pointers to other helpful information about product ownership, product management, portfolio management, and strategy.

In order to make the game effectively simulate what happens when a team is working through a backlog, Dajo and Paul created a deck of cards that include Feature cards


and User Story Cards.


The mechanism used to track work (i.e. output) is very familiar – story points. The key idea for this post is what the game uses to track value – business value points. In fact, the goal of the game is to be the team that delivers the most business value points.

Dajo and Paul did not create the idea of business value points for purposes of the game. The idea has been around the agile community for almost 10 years and is based on the following assumptions:

  1. We want to know about business value to help us make decisions.
  2. It’s better to measure and track the business value we deliver rather than the work we do to produce it because that helps us to determine success based on delivering outcome rather than just output
  3. Business value is difficult to measure and track because it is subjective in many situations. This is especially the case for user stories that have been split so that they can be done within a sprint.
  4. We don’t want to spend too much time trying to estimate business value because it takes away from actually delivering it.
  5. We can use the analogy of story points as a way track and measure business value that doesn’t take too much time to estimate.

Here are several different posts describing the idea and advocating it’s use:

Business value points sound great, don’t they? Several of the puzzles that came up as a result of playing the game surrounded that idea:
A) Calculating business value at the story level
B) What if the PO doesn’t want to estimate value?
C) How do you determine point value?
D) How to effectively determine business value points
E) How to accurately establish business value

I could answer questions A,C,D,E with the following guidance:

  1. Get your stakeholders together
  2. Give them each a hand of cards with each card representing values along the modified Fibonacci sequence (1,2,3,5,8,13,20,40,80,100 for example). You can even reuse your team’s planning poker cards for this!
  3. Have the stakeholders play planning poker with each story, but instead of determining the relative size required to deliver the story, have them determine the relative value of each story.


  • that guidance doesn’t really indicate what value a point has (it’s a unit-less unit of measure like story points)
  • I’m not sure how effective that approach really is
  • I’m not sure how accurate it is either (though I’m not sure how much I care about that.)

Plus, the person who asked B in some respects was on to something.

Look back at the first assumption that resulted in the creation of business value points: “We want to know about business value to help us make decisions.” There are a couple of considerations with this:
1) Business value means you reach the outcome you want to get to.
What do I mean about outcome? It’s the need you’re trying to satisfy or the change you’re trying to make. In this sense, you’re looking to your understanding of business value to determine what you work on and what you don’t. Doing the things that bring business value means do those things that help you reach the outcome you seek.

2) How do you know when you’ve succeeded?
Ideally there is some measurement of the outcome you produce. Years of working on projects has conditioned us to want to track things in a continuous fashion (X dollars, Y weeks, Z story points). Outcomes may be a measure, such as an increase in the number of subscribers a website has, or the amount of revenue that a product produces. They may also be binary. You have either solved the problem, or you haven’t. Even when the outcome can be measured in terms of subscribers or revenue, the impact of software development work is generally not direct or continuous. You may have one particular change that will present a large stepwise movement toward the outcome you are looking to accomplish. In other cases, you have to make several changes that will work together to generate some movement toward the outcome. The changes your team makes do cause movement toward an outcome, but it’s not an additive thing that means you can say “this story is going to get us 5 points toward the outcome” and “this other story is going to get us 8 points toward the outcome.” You have to make some changes, put them into place, and then measure the result.

This is where the phrase falsely attributed to Yogi Berra comes into play: “In theory, there is no difference between practice and theory. In practice, there is.”

I’m betting that most of the people who advocate using Business Value Points have good intentions. They want to get away from making decisions based on the amount of work (cost) required to deliver a particular change. They know that tracking progress based on story points is not necessarily the way to go, that it focuses too much on output and it can lead to a team doing a lot of work to deliver something that really doesn’t drive much movement toward the desired outcome.

But here’s the thing: measuring business value points is still measuring output. You are measuring what you have done just based on a different perspective. You don’t really know for sure if you are doing the right things. Sure, items that have more business value points should correspond to the right things, but consider how those scores are derived. They are relative scores saying this backlog items is more valuable than this other one. The tricky bit is whether that value is determined based on getting closer to the desired outcome or whether they were determined in isolation.

Business value points could be helpful for making decisions by looking at multiple items and saying that the ones with higher business value points are most likely the better ones to do, but I don’t think I would use an aggregate number of business value points to tell me when I’m done. Sure, I can see how much I’ve delivered, but I don’t know the actual impact on the outcome I’m trying to reach until I measure my metric of choice.

If you use business value points to make decisions, that means they are still worth something, right? Perhaps. If all you are using them for is comparing items to each other, ask yourself “do I need to go to the extra effort of putting points to them, or can I just look at the items you are comparing and do the equivalent of the eye doctor test (better first or second)?” Doing direct comparison of value between items may not require numbers at all.

Perhaps you find numbers useful, but you don’t need to do the relative sizing. Instead use different criteria for the numbers you assign. Brandon Carlson shared an approach that he used which seemed to work well in situations where he had multiple stakeholders who were all involved in making decisions: Story prioritization at the “Blink” of an eye.

I don’t advocate sizing items in a backlog and then measuring success as the point where you’ve delivered the total number of business value points that were in the backlog. That leads to waste:
1) The time spent relative valuing all of the backlog items.
2) Defining success as delivering all of these business value points means that you will most likely end up delivering things that really aren’t needed.

Think about it this way. You initially create your backlog at the beginning of an effort, when you know the least about the project. Your knowledge about the problem and solution will inevitably grow as you move along. (If your knowledge is decreasing as you proceed, you’ve got bigger problems.) When you make your initial guess at what will drive the outcome you are seeking, you are doing so with incomplete information. You are going to learn along the way, and that refined understanding will cause you to identify some additional items, and also realize that you don’t need everything that you had originally identified. Sometimes because you didn’t understand the solution, sometimes because you misunderstood the problem, sometimes because your priorities changed.

Once you start changing things, and you’ve identified success as completing a certain number of points (either story or business value) you end up in a quandary. If you missed a lot of things, your “measurable success” number is too low and you have to figure out what you want to do. Keep in mind it’s still important to have the appropriate time/cost constraints (if they are present) because this provides additional information to help you make your decision. But the discussions you have should be:

we have 6 weeks available to us. What are the right things to work on during those six weeks to get us where we need to be?


How can we get 200 Business Value Points done within those 6 weeks?

If you go the later route, you could successfully deliver your 200 points of Business Value, but the combination of the changes you make is not the right combination that makes a viable solution, or they provide changes in an area that was not really the focus of the project because you chose to focus on “low hanging fruit.”

The other problem (and frankly a good problem to have) is that you identified more items than are necessary. If you define success based on delivering the complete list of scope items, or delivering 200 business value points, you could find yourself going down the road of delivering functionality in order to meet that goal, instead of making your decision based solely on whether that functionality is needed to achieve the desired outcome. Going that route results in delivering more functionality than is needed, leading to wasted time (which could have been spent refactoring existing functionality to make it easier to maintain and more robust) and added to the maintenance load down the road.

So how do I measure business value? By finding a business focused metric that describes the outcome I’m looking for and then testing how the output I produce impacts that metric. I’ll write about that in a future post. But in the meantime, I’d be interested in hearing about your experience with business value points, and also what you have used to measure business value.

The above ideas are heavily influenced by a post from Pascal Van Cauwenberghe: Estimating Business Value   and the insights of Chris Matts.

Dealing with Dependencies

When I facilitated the Product Owner Value Game at IBADD2016, I asked the participants to suggest some things about the activity, or product ownership in general that puzzled them. One of the items was one word written on a sticky note.

There is a lot involved in that sticky note. Dependencies have always been an issue, but until self managing teams and stand-back leadership became popular, teams could always look to others to handle dependencies. This didn’t always work very well, but at least the teams had plausible deniability.

What I suspect the person who wrote that post it note was really asking is “how do we deal with dependencies in an agile environment”. I have found a few strategies that work well for dealing with dependencies, and generally put them into four categories:

  • Get rid of as many dependencies as you can.
  • Deal with dependencies inside your team
  • Deal with dependencies between teams working on the same project/product
  • Deal with dependencies with teams outside your project/product.

Get Rid of as Many Dependencies as you Can

The best way to deal with dependencies is to not have them at all.

In reality You won’t be able to get rid of all of your dependencies but you can get rid of quite a few. The trick to doing that is uncovering the source of the dependencies.

Dependencies occur because work is divided up between the team in a way that requires one thing to be done before another item can be done. Organizing teams based on activity – Analysts, Designers, Developers, Testers – where you have a team of analysts do some work then toss it over the wall to designers, and so on causes this problem. Building a cross functional team can often help this issue. You may also run into this problem when you divide the work up along architectural layers – one team does all the database work and another team does all of the user interface work. More often or not, this is still dividing work based on activity, but in this case it’s mostly on technology lines. Proper story splitting can help prevent these type of dependencies.

Dependencies also occur based on the number of people involved in a project. Sometimes you can avoid having a large number of people on a project, sometimes you can’t. It depends on the size of the problem, the size of the solution, and how quickly you’d like to solve it. I’m inclined to believe if you dig deep to understand the problem you are trying to solve in the first place, you may avoid dependencies by gaining better clarity on the problem they are trying to solve in the first place. If you don’t need a big team, don’t use one. Identify a very limited, very specific problem and identify a specific solution to resolve it.

Finally, dependencies come about when you split the work based on the steps of the business process you are supporting. This approach often leads you to believe that you have to deliver the functionality in the same order in which it is used. This belief results in perceived dependencies that don’t really exist. Instead of building things in the order that they will be used you can pick an order of implementation based on which way will help you learn the best and require the least amount of coordination as opposed to doing it in a very specific order which may call for more coordination.

There are going to be some dependencies that you can’t avoid and will just have to deal with. You have some options for dealing with them, and those options vary depending on if the dependencies are:

– inside your own team (within your span of control)
– with other teams working on the same project/ product (within your span of influence)
– with other parts of the organization.

It’s instructive to look at all three scenarios because the strategies for dealing with dependencies differ in each case.

Dependencies Inside Your Own Team

If you have to have dependencies, these are the ones you want to because they are completely within your span of control.

Assuming you’ve gone through the though process described above and still have dependencies within your own team dealing with them becomes a matter of identifying the dependencies and discussing with the team what’s the best way to sequence the items to minimize their impact.

The way you approach sequencing depends on what approach you are taking toward your work. If you are taking a time boxed approach (i.e. Scrum) where you plan the items you are going to work on for the next time box (i.e. sprint) and then lock down what you are working on until the end of that time box, your basic decision is whether it makes more sense to bring the items with dependencies into the same sprint, or to explicitly schedule the predecessor in one sprint, and the successor in a subsequent sprint. The route you go there depends on the size of the items that have the dependency and what the nature of the dependency is. Dependencies of this nature occur where you create some initial functionality and then have future work to expand upon that functionality. If you go this route, you will see some value in delivering the foundational functionality to your stakeholders and get feedback before expanding capabilities too extensively. The feedback you get may tell you that you do not need to extend your capabilities, or will at least give you guidance on what capabilities to expand.

If you are approaching work in a continuous flow manner (as suggested by Kanban), your decision basically comes down to when do you tackle the predecessor, and how long do you wait to deliver the successor items, so in many cases the decision may be a little more clear cut. The suggestion about pausing between delivery of the predecessor and the successor to get some feedback still holds true in this case, and you may find you have a bit more flexibility as to how long do you go between delivering the base functionality and the extensions.

Of course, this line of reasoning assumes that you have explicitly identified the dependencies that exist between items and your team has had conversations about how you would like to handle them. I’ve found it helpful to include consideration of dependencies (both inside and outside the team) in my definition of ready so that it acts as reminder of the team to at least discuss whether any dependencies exist before they launch into delivery on an item. You may want to go beyond merely identifying that a dependency exists and discuss the nature of it as a team, or at least with the relevant members of the team involved, so that you have a clear idea of the impact of the dependency when you start delivery work.

Dependencies on Other Teams Working on the Same Project/Product

Dependencies outside of your team are more involved to deal with primarily due to the amount of control or influence the teams have on each other. If the dependency is between two teams working on the same project or product, you should at least have some influence over whether the other team picks up the dependency and delivers their end of the bargain. This is mostly because both teams are (hopefully) working toward the same goal.

The Scaled Agile Framework (SAFe) provides guidance for dealing with this type of dependencies in their program level. One of the main activities in Program Increment (PI) Planning is for all the teams working on a product to identify dependencies with other teams, note what those dependencies are, and discuss those dependencies with those teams. The idea of getting people talking together to note dependencies is a great one, though I still wonder about the effectiveness of it is to bringing over 100 people together for those 2 – 3 days. Yes, it gives everyone a say, but when you have that many people involved you find that you have several people who are not involved in the discussions. But this is not a post on the merits of PI Planning in SAFe.

Identifying dependencies is one thing, but the rubber really meets the road when it comes down to what those teams do with that information once they start delivering. Just as inside the team situation, the idea of getting together and identifying and discussing dependencies is so that the people involved can come up with a plan for addressing them and make the appropriate decisions along the way. The same is the case in the dependencies between teams, and the part that you may easily forget is to KEEP TALKING to the teams that you have dependencies with after planning. Touch base on when the team is going to work on the dependency. Discuss any key interfaces or agreements that the teams need to have – it’s in this case where having discussions, and then writing the agreements down can prove to be very helpful. Documentation still has it’s place.

Dependencies between two teams within the same project or product are within the teams’ span of influence because an effective project/product team generally establishes agreements on how teams with dependencies will work together to get those dependencies cleared. Failing that, the teams most often work in the same part of the organization, so problems with inter team collaboration can be escalated when the teams themselves seem unable to work it out, and those escalation paths are clearly identified. In a lot of cases, the project/product team may have people whose main responsibility is making sure that those conversations happen (for example Release Train Engineers).

Dependencies on other Teams Outside the Project/Product

The dependencies that you have with teams outside of your product or project prove to be the most difficult to clear, primarily because you certainly don’t have any control and rarely have much influence. These dependencies arise when one team relies on a central services group to perform some task for them, or when one product finds that the easiest way to address a need is to use functionality produced by another product.

The key strategies to deal with these types of dependencies remain the same as with teams working on the same product:

  • Identify the dependency
  • Establish an agreement between the teams of each others responsibilities (for example, documented interfaces)
  • Communicate while work is under way to make sure all the teams involved understand the current state of any work.

The big difference is that if one of these steps does not occur, or the teams have a breakdown in communication, the escalation path is often not as clear, and internal politics become a bigger hinderance in dealing with any issues.

The best way to avoid this problem (other than not having dependencies with other teams) is to openly discuss how the teams will work through any challenges they run into and in effect agree to their escalation path before one is needed. This type of conversation rarely happens because teams generally believe they won’t need that type of arrangement. Ironically, it’s those teams that most often find themselves some way of resolving disagreements.

Yes, I’m effectively suggesting that these teams work out a contract of sorts so that they have an agreed upon method of addressing challenges when they arise.

Folks could say that flies in the face of Collaboration over Contract Negotiation. Perhaps, but what I’m suggesting is establishing some agreements when teams first start working together so that they can collaborate effectively before the relationship deteriorates in such a way that all of the interactions between the teams becomes contract negotiations. I have found when working with outside vendors that a bit of well thought out discussion about how the organizations will work together at the beginning will make the interactions after the fact much more productive.

Common Sense, Not Common Practice

There really is no silver bullet, no magic technique that teams can use to address dependencies. It comes down to avoiding dependencies as much as possible, and when you do have them, communicate about them. Discuss the dependency when it’s first identified. Discuss who is responsible for what. Let those who are dependent upon you know where things are at. Confirm that those you are dependent upon have actually addressed the dependency. This sounds easy to do. It sounds like a no brainer. But like many other things, when teams get in the heat of the moment, they often forget those common sense actions. If you deal with a lot of dependencies, you may find making some of these ideas common practice will make your work go much smoother.

How to Balance Discovery and Delivery

When I facilitated the Product Owner Value Game at IBADD2016, I asked the participants to suggest some things about the activity, or product ownership in general that puzzled them. A couple of the Puzzles brought up were:

  • The math behind exploration & reward of doing so
  • When to commit to deliverable vs additional research

To answer these two questions, I’m posting an excerpt from Beyond Requirements: Analysis with An Agile Mindset. This particular excerpt is from Chapter 2 – Helpful Concepts and discusses the idea of Discovery and Delivery.


The third way of categorizing analysis is along the lines of when we do it. It is often helpful to compartmentalize activities. This is probably one of the reasons that people latched onto the various phases described in plan-based approaches (analysis, design, development, testing). There are certainly some advantages to splitting up the activities that go into knowledge work. No single person is really good at every aspect of knowledge work, so organizing the activities into groups can certainly help break things down into manageable chunks and apply focus to the various aspects.

But what is the best way to organize those chunks? When people reference the Winston Royce paper that is cited as the source of waterfall planning ( Software-Systems.pdf), they usually zero in on the diagram showing several different phases that occur when building a large system. But on the first page, there is an interesting and often overlooked picture of two boxes, “Analysis” and “Coding,” along with the following comment:

There are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it—as is typically done with computer programs for internal use. It is also the kind of development effort for which most customers are happy to pay, since both steps involve genuinely creative work which directly contributes to the usefulness of the final product.

Royce goes on to say that this approach is woefully inadequate for larger software development projects and reveals a bit of his philosophy about how to treat software development teams:

An implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed to failure. Many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay for them, and development personnel would rather not implement them. The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.

While I don’t agree with everything in that passage, I find it interesting that Royce focuses on analysis and coding as the two activities customers value. I had been searching for some straightforward way to describe the key activities in IT efforts which, based on my own experience, tend to break down into “figuring out the right things to build” and “building the things right.”

Ellen Gottesdiener and Mary Gorman identify the right words to put around those ideas in their 2012 book Discover to Deliver. There it is: discovery and delivery. It has alliteration and everything. They further cement the concept by wrapping the two words in an infinity symbol to represent how both activities interact and influence each other. Royce would be proud that someone finally listened.

Here’s how Gottesdiener and Gorman define discovery and delivery. I’ll assume these definitions going forward in this book.
Discovery: work that explores, evaluates, and confirms product options for potential delivery
Delivery: work that transforms one or more allocated candidate solutions into a releasable portion or version of the product

The most helpful aspect of this concept is having a label to associate with different types of activities. Traditionally teams have tracked what was going on from a delivery perspective but have frequently not visualized discovery activities. Tracking their efforts to figure out the right thing to build can be just as helpful as tracking how they are building the solution, so I often use separate discovery and delivery boards. I’ll talk more about those in Chapter 15.

All aspects of knowledge work involve some aspect of discovery. We’re still “discovering” things about the need and solution when we’re in the process of building it, testing it, and deploying it. It’s useful to differentiate the two activities to reinforce the focus of each activity. Discovery increases your understanding of the need and solution to set up delivery. Delivery is primarily about building, testing, and deploying output, but those activities help your team build further understanding of the need and solution, which in turn influences your discovery. Sure, discovery still happens in delivery, but the majority of work done there is building stuff to help increase understanding.

To really know when you should move from Discovery to Delivery, I find the idea of the definition of ready to be helpful. I discuss the Definition of Ready in this blog post, and also in Chapter 15 of Beyond Requirements.

Dealing with the Quality of Estimates

When I facilitated the Product Owner Value Game at IBADD2016, I asked the participants to suggest some things about the activity, or product ownership in general that puzzled them.  One of the puzzles was “How to Anticipate Quality of Estimates.”

I suspect this item was inspired by the characteristic of the game that introduced a little bit of uncertainty by having different values for Story Points and Business Value points on the front of the card versus the back. It may have also been sparked by some comments regarding estimates are generally going to be wrong.

If I had to sum up all the different perspectives regarding dealing with estimates, I’d suggest the following:

1) Base your understanding of estimates on a historical perspective.

This can be true in a couple of different ways. First, when you are trying to estimate something new, spend most of your time comparing to things that you have already done. For example, I have found that the last couple of times I added a the pages for a new conference to the agile alliance website, it took me about half a day to get them all posted. The time varied based on the size of the conference and how much information we were posting, but half a day is generally how long it would take. So, the conference I have to add, once I get around to doing it (time in queues is often the thing that screws up time to completion estimates the most) I know it’s going to take me about half a day.

Second, take into account the typical error involved in your estimates, or your team’s estimates. Before I started working in an agile setting, I used to apply the rule of pi to estimates from a particular Architect. Every estimate I received from this architect was usually way low, and I found that if I multiplied his estimate by pi (3.14159265359) I would usually end up with a much more usable estimate. I used historical experience to influence what I did with current estimates.

2) Don’t worry too much about precision.

“But wait!” you might say.
“You just said that you would multiply an estimate by pi and listed it out to 11 decimal places, and now you say ‘don’t worry too much about precision’? WTF?”

That was a joke.

I didn’t multiply the estimates by pi to the 11th decimal place, I usually just tripled them, which was good enough. I use pi when I tell the story because it’s funnier. Kind of like 42 makes a good Ultimate Answer to Life, the Universe, and Everything.

Estimates are based on small amounts of information, a lot of assumptions (stated or unstated) and just some plain old guessing. Extreme precision doesn’t add much value and can be misleading. Instead of providing very precise estimates – “it will take me 27 days” you’d be better off by going with a little bit less precision such as “a little bit more than a month” or better yet as a range “1 – 2 months”. The more you can signal your appreciation for uncertainty, the more honest you are being with the people who asked for the estimate, and the more honest you are being with yourself.

3) Understand what the people are using the estimate for.

When people ask how long something will take, or how much it will cost, they are often trying to determine whether or not it’s worth doing. If that is the decision they are trying to make, order of magnitude estimates – this will take days versus this will take months – will often be sufficient. If they are using the estimate to start planning corresponding activities, or to set aside the proper amount of money, then you may need to be a little bit more precise, or you could ask more questions.

Let’s take the example where you are asked for an estimate so that your team can plan the corresponding activities that go around product launch. Instead of providing an estimate or worrying about more precision, ask how long those other activities usually take. Many supporting activities usually are a bit more consistent, and as a result have a more stable time line. Find out how long those other activities usually take. If you sense whatever you are doing is going to take longer than those other activities, agree to do some work and then provide a more informed estimate later, or just give a heads up that the other steps should start happening.

Another question you can ask when you are asked how long is something going to take is “when do you need it?”. Then if the time frame in which the new work is desired is way shorter than what you can deliver the work in, find out if there are ways to reduce the amount of work you do while still meeting the desired outcome. You may be only able to meet the outcome for specific scenarios, or assume a very simple way for addressing the problem. A similar question comes about from a budget perspective, and you’ll find that more often than not, people have a number in mind of how much a particular change is worth to them. I call this approach “movie phone estimating”. It allows you to change the conversation from estimating limbo where you’re constantly being asked “how low can you go” and guessing what number to match and instead work with known constraints and can apply some creativity to delivering the desired outcome within those known constraints.

4) Put the appropriate amount of work into doing your estimates.

If you follow the first three pieces of advice, you’ll find you have a good guideline to know how much work to put into getting your estimates. The general answer is “not much.”

You usually put estimates together at the beginning of a project when you know the least, so it doesn’t make too much sense to spend a lot of effort estimating. You’re not going to learn a bunch of additional information that way.

That’s why James Grenning suggested planning poker and it’s variants. That’s why the #noestimates folks suggest that counting stories may be an appropriate alternative to spending a lot of time even doing planning poker. That’s also one of the implied findings from a study that Todd Little describes in his post To Estimate or #NoEstimates that is the question.

I wouldn’t worry about the accuracy of your estimates as much as whether they are providing useful information for making decisions. If you find you are consistently making the wrong decision based on the information that estimates are providing, then I’d look into how you are doing your estimates. If the flaw comes from other sources, then don’t try and fix what ain’t broke.

Role of a BA in Agile

“What is the Role of a BA in an Agile?”
I see this question asked quite a bit.  I’d like to suggest that rewording the question may be a bit more instructive.  Instead of wondering what the role of a business analyst is in agile, you may want to ask the question “how can people who have filled the role of business analysts in other settings contribute effectively in an agile setting”?

Various agile approaches treat roles differently.  Since Scrum is the most frequently adopted, it’s the model most often associated with agile in general (right or wrong). Scrum effectively did away with roles altogether, except for three: Scrum Master, Product Owner, and Team. Folks who have previously filled business analyst roles can and often do find themselves filling anyone of those three roles, not because they were a business analyst, but because of their personal skill sets. Typically though, people with a business analysis background get involved in some form of product ownership.

Context tends to play a big part in determining how someone with business analysis skill sets contributes in an agile setting. My friend Todd Little, who has a great deal of experience leading development organizations in an agile setting put the following graphic together to show the different models that exist in actual practice.


The first model where the Product Manager or Business Leader is the Product Owner tends to be more common in Product Organizations than in internal IT situations because the person filling that role has business analysis skills (often in this case referred to as Product Management skills) as part of their job.

In the second model, the Product Owner is a separate role from the Product Manager or Business Leader, but reports up through the business part of the organization.  This model can be seen in both product organizations and internal IT settings. If the organization had business analysts sitting in the business units, they may often see their titles changed to Product Owner.  In this scenario, the Product Manager/Business Leader sets the roadmap and does global prioritization, while the Product Owner handles more local prioritization and is mainly responsible for writing and clarifying user stories.  This model often shows up in organizations where there weren’t business analysts in the engineering/IT part of the organization (shown in the model above as Product Development).

The third Model has Business Analysts on the IT side and no specific Product Owners.  This model tends to be more prevalent in internal IT settings than Product companies and is usually what happens when the organization had business analysts that belong to the IT organization.  Often the business analysts in this setting end up playing the role of Product Owners, sort of, in that they are working to make sure that decisions happen, though they may not have the decision making responsibility themselves. In this case, the Business Leader sets the roadmap and does global prioritization (often only after nagging from someone sitting in a business analysis role) while the business analyst again does local prioritization (sequence of items on the backlog of the team they are working with), and writes and clarifies stories.

A variation of the third model which I have seen is where there is a Product Owner on the business side who is responsible for making sure a roadmap is set and there is some global prioritization (although they don’t have the authority to make those decisions themselves) and the BA still takes care of their local responsibility.  This model most often occurs in Internal IT settings where the Business Leader feels so loaded down with other responsibilities, that they need someone to handle the Product Ownership aspects of their responsibilities.  In this model, the person on the Business Side is titled Product Owner, and the folks doing product ownership on the IT side are often titled Business Analyst.  This model can lead to a great deal of overlapping responsibilities and large gaps, mainly because each person assumes the other is taking care of a particular issue and so neither end up taking care of it.

One way to determine what model to pick is to explicitly who is going to do what.  RASI charts are good tools to guide this conversation.  You can start by identifying what specific roles are expected to do, then change things based on the actual people on the team and their skill sets.  You may find that the actual activities that people undertake differs a bit from the role they are filling is usually expected to do.  In some settings this is viewed as one person filling multiple roles, something which I did quite a bit when I was contracting.

Inconvenient Truths in IT Projects

I am preparing a presentation called Inconvenient Truths in IT Projects where I plan to discuss some aspects of software development that are prevalent and need to be discussed, but people don’t like to talk about in polite company.

Some of the topics I’m throwing around:

  • No matter how hard you try, your estimates will be wrong.
  • The more an organization proclaims they are “doing agile” the less likely they are using it in a way where they (or more likely their clients) will get true advantage from it.
  • Your IT organization is trying to do too much.
  • There is no such thing as “best practice”
  • Complexity is not the best way to deal with complexity.
  • The plan you created at the beginning of the project is wrong.
  • A (potentially sizable) portion of scope creep is a result of learning
  • The more complicated your process is, the less likely your teams will follow it.
  • In the absence of an understandable, actionable strategy, people will make up their own

Do you like any of those?

Are there some that are missing?

Let me know in the comments.

Analysis Techniques LiveLessons

LiveLessonsLast fall I worked with Addison-Wesley Profession to create a set of LiveLessons to provide additional coverage of the techniques described in Part 3 of Beyond Requirements: Analysis with an Agile Mindset.

Analysis Techniques for Product Owners LiveLessons is a video training course providing methods for understanding project stakeholders, the organizational context in which a project is occurring, the need a project is trying to satisfy, how to build a shared understanding of the solution the project is delivering, and how to organize and persist solution information, all while knowing when to apply the techniques covered.

Find out  more about the LiveLessons here.