Clients will often ask me what the “secret sauce” is to effectively prioritize a product backlog within the context of an Agile or Scrum project. Without a well-prioritized product backlog, it can seem like development goes on-and-on forever, with no real end in sight. After all, one day you’d actually like to be able to […]
Clients will often ask me what the “secret sauce” is to effectively prioritize a product backlog within the context of an Agile or Scrum project. Without a well-prioritized product backlog, it can seem like development goes on-and-on forever, with no real end in sight. After all, one day you’d actually like to be able to release the thing and bring value to your users.
The answer is contingent on several factors, so you need to ask yourself several key questions before you decide:
Different users will have significantly different tolerances for change or defects, and as an organization, you will have different metrics for defining success. If you are delivering a public-facing website, you may have a more elastic response to change, and a higher tolerance for defects. In this case, you may have a high focus on new features, over defect reduction.
Conversely, if you are managing an enterprise solution, quality may be more important, and you may want to focus on defining your key data and key processes. Quality may not directly impact the priority of your stories, but it certainly will inform your team’s velocity and thus how much or little you can prioritize.
We’re all taught to think that our IT projects have a firm time, scope, and cost. Just don’t believe it. Something’s got to give. Often a project will have a really tight budget or a hard-and-fast schedule. Priority management is the best way that you can gain some wiggle room without impacting cost and schedule.
What is the minimum set of features that you can deliver and still have a big impact? There are thousands of features in Microsoft Word, but your average user only uses maybe 20% of them. Do you think that Microsoft delivered style sheets on Day 1? Doubtful. Limiting a project’s scope isn’t being dishonest. It isn’t slimy. It’s a technique for risk management and lets what your real priorities are.
Once your product is already in production, you have a great opportunity to get into a rhythm of getting feedback from your users on what’s working and what isn’t. If your product is a website, you’ll need web analytics information, and depending on size and budget, you should consider getting independent web satisfaction from a company such as ForeSee. Read what your users are telling you. Find other ways to understand what your users are telling you. If you have a search feature, find out what your users are typing.
If you are still in beta, get in front of your prospective users as early as possible. Get the largest sample size you can. Acceptance test your software. Hold focus groups with your stakeholders. Depending on the product, consider rolling your site to production to get real feedback from your users on what’s good and what’s not so good. But think this strategy through carefully!
Ok, these next two questions are a little bit tougher to answer. You need a product vision first to really understand what it is that brings business value to your product. What is your customer value proposition? How can you lower costs to your company?
Many of us in the DC area work with the Federal government, and we must focus on what brings mission value. Same principle, but often harder to add a price tag. That being said, Federal missions are great for understanding what is important to your users and your agency. Read your agency mission statement aloud. Put a picture of your user on the wall. Is this for the Warfighter? The customs agent? Whatever it takes to drive the point home that if it doesn’t lower cost, increase the value to those using it or affected by it, then it probably doesn’t matter (as much).
Here’s the harder sell to your managers: do not forget the future! The more you are able to think about how to improve the operational efficiency of your product, the more you will be able to demonstrate your strategic value to your organization. The return on investment for including technology upgrades gets a little squishier when we’re talking about staving off future problems. But, sometimes you need to blow insulation into your attic before you can buy new furniture for your house (future planning before aesthetics). Some likely high-value features that fit this “nuts and bolts” category include security upgrades, infrastructure improvements (adding servers, perhaps), or implementing automated deployments.
The bottom line is that product management is about knowing your value proposition, your profit formula, your users, and your gut. Do you have other questions you ask yourself when prioritizing a product backlog?
Agile experts think great product owners act as entrepreneurs for their product. Product owners and...
You are probably familiar with some form of the following: Should we be using story...