Manage customer expectations the Agile way

Here’s a thought-provoking piece by John Peltier about ‘selling’ roadmap items to the business.

John discusses ways to make sure that customers aren’t given unreliable promises about the delivery of features or smaller roadmap items. Among other techniques, he suggests being clear to customers about the difference between dates that are the result of proper work estimation by engineers and ‘draft’ dates that are the result of less reliable estimation methods.

John also touches on what can be one of the most bruising aspects of the product owner role: refusing to be steamrollered into re-prioritising the product backlog simply because items have been promised in error (often by a salesperson).

In fact, managing the expectations of customers, salespeople, marketers, managers and developers is one of the key roles of the Agile product owner.

Calendar with blue pills

Image: stock.xchng / tinpalace

Business people who are used to waterfall projects are used to the idea of having a plan that gives dates for when all features will be delivered – and they’re also used to the almost inevitable failure of that plan.

So Agile techniques such as only attaching dates to roadmap items that have been estimated properly are likely to invite skepticism initially. It’s through consistent delivery on the few promises that we make that we educate our stakeholders and build their trust.

That, and the wonderful flexibility that Agile allows – “You need to respond to an unexpected business challenge with an urgent new software feature? Sure: let’s talk to our developers to see if we can put back feature X and deliver what you need in a month’s time” – give product owners credibility so that we don’t need to feel that we must make promises that we suspect we can’t live up to.

One useful technique that John doesn’t mention is to attach a ‘Needed By’ date to features – but only when they are genuinely needed by a specific date. That way, each time the product backlog is worked on, the product owner can decide whether each of those time-sensitive features need to be re-prioritised. In some cases, this will mean de-prioritising a time-sensitive feature or implementing a workaround because it’s clear that higher-priority items will mean that the feature cannot be delivered when it is needed.

Such small-scale feature-level ‘failures’ are actually a strength of the Agile methodology. It’s because Agile projects are able to fail at the small level, with full visibility of the failure to all stakeholders, that they are resistant to failure at the large scale.

Posted in experts, techniques Tagged with: , ,

Product owners and web analytics: advice from Avinash Kaushik

Product owners working on web projects need to understand about web analytics for two interlinked reasons.

First so that they can understand which parts of their site are most used, which are less used, which bring in most revenue, which cause confusion in users – and in what order users visit pages.

The second reason is so that they can specify what analytics are required for their own needs and for the needs of other people responsible for the site.

Avinash Kaushik’s brilliant Occam’s Razor blog delivers a fast and deep introduction to what’s what in analytics. Many of the best articles are a year or two old, but they bring wisdom and experience that is still very relevant.

Start with ‘Web Analytics 101: Definitions: Goals, Metrics, KPIs, Dimensions, Targets’ and have your analytics tool ready while you read so you can try out the ideas. Avinash recommends using the free Google Analytics tool. Or, if your organisation has already bought and configured a more costly and complex tool then you should stick with that.

By the time you’ve finished working through Avinash’s Web Analytics 101 you should feel that you have a good initial grip on how your tool works. Avinash recommends just getting stuck in and trying things out. After a little of that, you may feel that you have some understanding of what you can do with analytics.

Now is the time to read Avinash’s ‘Beginner’s Guide To Web Data Analysis: Ten Steps To Love & Success’, where he helps you to take a step back for a more strategic view of how well your site achieves what you want it to achieve. The ten steps are what Avinash might complete in a day’s analysis of a site. If you’re new to this, it’s likely to take you a week or more – so ask for help from a technical expert if you have access to one. The page is a couple of years old so some of the reference links are broken and you’ll need to search for the information referred to instead. It’s worth the effort because after you have completed these ten steps (and followed some new paths that your investigations will have lead you to) you will have a good knowledge of how to find out how your users are actually using your site.

By now, you will probably have insights about the usage of your site that no one else has – and almost certainly not your management. Such knowledge is very hard to communicate clearly – partly because we all have strong preconceptions about how a site is used, based mostly on our own limited use of it. Avinash’s ‘Excellent Analytics Tip #21: Convert Complex Data Into Simple Logical Stories’ explains how to create compelling and accessible arguments from analytics data. Be warned though that there’s no simple formula, and you will have to work your data hard and think carefully to ensure that you’re presenting a useful and truthful picture.

Bang up-to-date for 2013, Avinash has published his illuminating ‘10 Data Analysis Strategies That Pay Off Big!‘, giving you some straightforward techniques for unlocking the value in your analytics data.

To complete your introduction, read Avinash’s ‘Web Analytics Segmentation: Do Or Die, There Is No Try!’. ‘Segmentation’ refers to the way you split up analytics figures to give meaningful information. For example, looking at the total site visitor count for a month doesn’t really give you much actionable information. However, splitting that into subtotals according to the route the visitors took to get to your site or according to how long they spent on your site or according to how much money they spent – now that is information that can be used.

Posted in blogs, experts, techniques Tagged with: ,

You won’t believe this ONE simple secret to running effective retrospectives ;-)

This technique is so clear and revolutionary that I couldn’t resist the scammy post title.

Dan Milstein, Director of Product Development at Wingu, recently gave a talk about running a 5Whys session (slides at the end of this post).

5Whys is a terrific way to solve problems properly – in a way that truly prevents them from happening again. The key insight is that problems have reasons, and the reasons have reasons. If you simply address the surface problem without addressing the underlying reasons, then that problem (or a similar one) is likely to trouble you again.

The failboat has arrived

Be prepared for a future where we’re all still as dumb as we are today.

5Whys is a great technique to use in Agile retrospective meetings, because great Agile teams are built through a process that continually improves itself – and 5Whys allows people to make deep improvements in their processes.

The 5Whys technique was made popular in the 1970s as part of Toyota’s very successful drive to improve the quality of their cars. The big win comes because the further you go up the chain of reasons for a failure, the more problems you solve – problems that haven’t even occurred yet. And solving problems before they occur is almost always cheaper and better for customer satisfaction than solving them after they have occurred.

In brief, the 5Whys technique involves working out the reason for a problem, then working out the reason for that, then working out the reason for that – and so on until you’ve worked through five levels of reasons.

At that point, you’ve probably reached the deep underlying problem. Fix that problem (and it may not look so much like a problem as a side-effect of an official policy) and you’ve really improved your process. Incidentally, in my experience, that fifth level of reason for a problem is almost inevitably at management or director level: there’s almost always a department or corporate policy that needs to be changed or tweaked in order for a problem (and it’s class of similar problems) not to recur.

Dan has identified three key barriers to running a 5Whys retrospective: people feel shame when they are implicated in the reason for a problem; people feel moralistic when problems are associated with mistakes made by other people; and these factors cannot be avoided because they’re part of what makes us human.

Dan’s genius idea shows us how to accommodate this natural human tendency to fall for what’s known as the ‘fundamental attribution error’. The reason Dan’s solution might be tricky to implement in some situations is because it involves a ‘non-business’ approach to running a 5Whys retrospective meeting. He says we need to use humour to circumvent our tendency to feel shame and blame. The good news is that he steps us through how to do it, giving examples you could use yourself. You start by humorously showing what the worst is that could have happened, or the dreadful things that have happened in projects. And you continue to use humour (always laughing with and not at meeting attendees) to guide the meeting through the reasons for the problem.

This method works: I’ve seen it applied (even though we may not have known that we were applying it). Dan gives a clear template for using humour to dispel blame and shame – and for creating real improvements through 5Whys retrospectives.

Genius indeed. All aboard the fail boat.

[slideshare id=15474125&doc=leanstartup5whyshumans-121203175503-phpapp01]

Posted in techniques Tagged with: , ,

Product owners need to sort the backlog as well as prioritise it

Jim Coplien and Brent Reid describe different but related reasons why the backlog needs to be ordered in order for a sprint to receive items to work on. The product owner will need to ensure that backlog items have priorities – but those priorities don’t provide enough information to work out the order that items should be presented for development.

Jim’s article gives a great example. Let’s say that we’re currently in November and there’s a medium-priority item in the backlog that will result in a Santa Claus image being displayed on a web site. There may be higher-priority items in the backlog, but if the Santa item isn’t developed before December then the priority of the item (and it’s value to the business) will fall dramatically. In fact, if we display a Santa figure on the site in February then that would probably have a negative value. So the decision that the product owner needs to make in this case, after discussion with other stakeholders, is whether to  present the Santa item for development before higher priority items – or whether to drop it until next year at least.

And there are other situations where an item might be presented out of priority order, such as small lower priority items that can be fitted in within a sprint alongside larger high-priority items. And even within one band of priorities (“We have ten items that are top priority!”) the product owner needs to decide which is the most appropriate order of development.

Posted in techniques Tagged with: , ,


The best way to improve a process is to study best practice, then think about what you’re going to do, then do it, and then review without blame what went well and what needs improvement.

In Agile, the review is formalised in a ‘retrospective’ meeting, and Olga Kouzina on the Edge of Chaos blog describes some great tools for reviewing your Agile project.

Posted in techniques Tagged with: , ,

Some wisdom from Henrik Kniberg

Henrik Kniberg is an Agile/Lean Coach and Agile Alliance board member. He blogs at and tweets at

I’ve referred to Henrik’s excellent video about the role of the product owner and how that fits into the overall Agile process on Agile Wisdom’s What is the role of a product owner? page. And his recent post about the way Spotify structures a large Agile team is fascinating (more information in this Techcrunch article).

Posted in blogs, experts Tagged with: , ,