Comments on: Plan Your Next Sprint By Bang For The Buck: Part 2

By: A Realistic Vision For Citizen Engagement Through Games

A Realistic Vision For Citizen Engagement Through Games — Mon, 04 Apr 2011 22:51:40 +0000

[...] As a conscientious blogger writing a three-part series, I don’t to merely repeat the previous posts. Instead, I want to offer other ways collaborative games can solve problems, including prioritization problems. One game that I think could work for governments who might like to try improve their internal prioritization efforts is known as “Bang for the Buck.” See Scott Selhort’s post on this topic here. [...]

By: A Realistic Vision For Citizen Engagement Through Games

A Realistic Vision For Citizen Engagement Through Games — Mon, 28 Mar 2011 06:59:59 +0000

[...] As a conscientious blogger writing a three-part series, I don’t to merely repeat the previous posts. Instead, I want to offer other ways collaborative games can solve problems, including prioritization problems. One game that I think could work for governments who might like to try improve their internal prioritization efforts is known as “Bang for the Buck”. See Scott Selhort’s post on this topic here. [...]

By: Борис Вольфсон

Борис Вольфсон — Tue, 22 Mar 2011 18:20:43 +0000

http://tynerblain.com/blog/2008/10/20/planning-sprints-part-2/ – приоритезация беклога на основе ценности/затрат #agile

By: Johan Lindberg

Johan Lindberg — Mon, 01 Dec 2008 14:47:30 +0000

Making a “bang-for-the-buck” diagram in order to plan our next improvement. http://tinyurl.com/5ty6xk

By: Roger L. Cauvin

Roger L. Cauvin — Fri, 24 Oct 2008 20:08:53 +0000

How does risk factor into backlog prioritization? A key benefit of agile processes is that the confront and address risks, whether they be requirements risks, architectural risks, deployment risks, or any other risks that occur in the product release cycle. While you certainly want to prioritize by value (to the customer) and cost, it's also important to factor risk mitigation into the assessment of priority. If deploying with a particular feature runs the risk of being a deal braker for the entire project, move it to the top of the priority list, as you want to confront and address this risk before wasting resources on other features, no matter how high their value and low their cost.

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 22 Oct 2008 12:32:44 +0000

Thanks, Luke! Really good advice for all of us. Thinking of it as a ‘tax’ seems like a good way to put it in perspective. Personally, I only like process when it helps me, not when it hurts me. So the idea of scheduling something that isn’t “otherwise next in line” when it makes sense (regardless of what the process says) works for me.

I hope that folks who read this article also read your comments, and can benefit to create extraordinary products.

By: Luke Hohmann

Luke Hohmann — Wed, 22 Oct 2008 03:20:37 +0000

Scott –
Yeah, you missed my point. This time I won’t be so subtle. As I pointed out in my blog series, truly extraordinary product management is not just about maximizing the revenue and lowering the costs. It is about managing a complex social system. That’s one reason why I include stakeholder analysis and alignment with corporate strategy. In some cases, you just gotta “pay the corporate strategy tax” and show how your product aligns with corporate strategy, even when you can’t really find a way to justify it economically. I appreciate the power of the Kobayashi Maru, but use it sparingly, my friend. Sometimes, just shoving a few backlog items to demonstrate alignment to corporate strategy is better than wasting precious cycles trying to make it something that it’s not.

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 22 Oct 2008 02:22:02 +0000

Oh – FWIW, I believe, given the available budgets, scope of the data and systems, and political environment, that the federated identity model (verus allowing continued distributed models OR forcing a centralized model) was the right one. But the fact that it was (IMO) “right” technically, was not the driver – it was the fact that some people with juice in the organization believed it was right.

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 22 Oct 2008 02:19:02 +0000

Luke – maybe I’m missing something in your example, but I would say that if something is a pure cost, don’t do it. Or if the benefit is far in the future, wait as long as practical to do it.

It may be that the ‘value’ is not within the scope of a single web property, but there needs to be value for the business, or it wouldn’t be needed. Maybe I’m accidentally sidestepping your point – if I am, please let me know.

With my first example, several properties were connected by my client in an attempt to create a cohesive environment for shared users. In many cases, a single story would take them (given the current implementation) through multiple solutions (developed by different companies and managed by different teams). There was value in reaching a common understanding of ‘identity’ along a few dimensions: user experience (both in maintaining a consistent LnF and in sharing information “across contexts” from property to property); security (allowing a single authentication mechanism to be used across properties); and analytics (understanding behaviors, abandoned funnels, navigation paths, segmentation). This value was easy to articulate at a “solution” level, even when not isolatable within a “single property” context. On this particular project, we used this “solution level” value to drive a roadmap. Expectation setting with the user base was the penultimate value driver (as it was believed to be the most critical factor in growth, and therefore profit), so both identification of valuable capabilities and the ability to commit to a delivery time frame (measured in halves and quarters) were the dog to the “design ideas” tail.

In the other project, we took the approach of investing in a federated identity model, primarily to meet a political perception that this would make different parts of the business as agile as possible. This created a separate project to deploy an MDM solution (focused on identity) that drove value for the independent projects (that also had to do work) with a focus on eliminating problems in their business areas that were caused by the inefficient coupling of these different “idiosyncratic” ways of managing identity. I guess that would be a Kobayashi Maru to your example, but we were still able to articulate value. The value elements for the individual businesses (of leveraging the MDM solution) justified development in the existing systems, and also drove prioritization of the MDM system development.

Did I get to where you were going with your question?

By: Scott Sehlhorst

Scott Sehlhorst — Tue, 21 Oct 2008 13:08:43 +0000

Hey Luke, thanks! And great complex-strategy question. I’ve worked on two customer projects in the last year that are both near your example. The first focused primarily on providing a cohesive and immersive online environment for users of a solution built by different companies. The second focused on the back-end, providing a consolidated view of “the customer” – compositing different notions of identity across the company (and across systems that evolved independently), to leverage silos of data to provide value across areas of the business.

The two projects had different political and strategic drivers. I’ll respond in more depth at lunch today or tonight when I get home.

By: Luke Hohmann

Luke Hohmann — Tue, 21 Oct 2008 03:55:57 +0000

Scott, I’m liking this better. One nagging concern deals with those backlog items that are related to strategic intent and/or political realities. To illustrate strategic intent, we’re working with a team that is merging together numerous web properties acquired over time via acquisition. Each acquired company had their own way of managing user identity and user profiles. They all work — just fine — and from the perspective of an individual Product Manager replacing (refactoring) their own idiosyncractic way of managing identity and profile information with the “corporate standard” is almost certainly going to be perceived as a pure cost. And they may be able to avoid it — but not forever. I handle this by simply allowing Product Managers to capture their need to “toe the line” for strategic intent. How do you handle this in your grid?

Luke