Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: What values are you using for Business Value

Expand Messages
  • RonJeffries
    Hi Whyves, ... Actually, no, we do not have to use an objective method . In fact, for almost every product we might be building, there IS NO POSSIBLE
    Message 1 of 10 , May 9, 2012
    • 0 Attachment
      Hi Whyves,

      On May 8, 2012, at 12:58 PM, Whyves wrote:

      At some point you have to use an objective method for deciding what is most important for the users of the product. 

      Actually, no, we do not "have to use an objective method". In fact, for almost every product we might be building, there IS NO POSSIBLE OBJECTIVE METHOD to decide what is most important. Objective prediction of the future does not exist.

      I can't help feeling that if a Product Owner finds herself wishing she had an objective way of deciding what to do, she does not understand her product and her market very well. I would expect to find that she has very limited contact with any real stakeholders and potential customers. When she has that contact, she will build up a very good sense of what is important.

      And when she just can't decide, she'll realize that the most important thing she needs right now is information. Needing information, she'll specify a couple of stories building things for users to try. Since we can build done-done software every Sprint, two weeks later she has running code that she can give to people and find out how much they really value those ideas.

      Your team is ready to do that for your Product Owner, are they not?
      If not now, when? -- Rabbi Hillel

    • Kurt Häusler
      ... If there is some objective method, and the PO finds value in using it then great. More often it is a very subjective process, and it is really one of the
      Message 2 of 10 , May 10, 2012
      • 0 Attachment
        On May 8, 2012, at 6:58 PM, Whyves wrote:

        > Thanks Kurt,
        >
        > At some point you have to use an objective method for deciding what is most important for the users of the product. It gives you insight on what you should prioritize. I don't really use the BV for individual Stories but more for Epics/Themes. When the backlog is becoming bigger and bigger, I think you need some kind of value to remind you of the importance of the Epic.

        If there is some objective method, and the PO finds value in using it then great. More often it is a very subjective process, and it is really one of the core aspects of the art rather than science of product ownership.

        >
        > What I find interesting is that you and Steve (another reply) provided the same answer as to not using the BV but instead just prioritizing the PBI. Is that what most people end up doing? There are a few articles out there talking about feature prioritization. Are they just noise in the real life of a PO?

        I think in the real word it is more common to see a simple prioritized backlog, rather than detailed attempts to quantify business value. The Scrum guide now mentions "ordering" rather than prioritizing the backlog, which suggests there might be other criteria to choose which stories should be done next than just priority. Risk for example.
      • gregc
        Yves, I was glad to hear you say you usually are trying to assess business value at the epic level as Kurt already pointed our it can be really difficult to
        Message 3 of 10 , May 10, 2012
        • 0 Attachment
          Yves,

          I was glad to hear you say you usually are trying to assess business value at the epic level as Kurt already pointed our it can be really difficult to non-meaningful at the story level. As to your question of whether I know what's most common in the industry, I do not.

          I do want to take a step back because as I'm reading between the lines in this thread, I'm wondering if your organization is clear on its strategy because business value needs to tie to that. For example, if you make commercial software and an opportunity presents itself to build a custom application for a new customer for which the total market for this application is one, it may deliver value (ie revenue) but it won't help you deliver on your strategy.

          The lenses I described previously are for looking at BV are at the feature level. You need to have already prioritized your market segments and the users in those segments. Has this happened?

          You also need to know what your company is looking to achieve. For example, if your business growth has stalled, then you need to prioritize new customer needs over existing customer needs. I don't know who gets to vote in the BV question, but this is where support will always prioritize existing customer needs because this is what they know about. Sales will prioritize the last objection they heard. Without the strategy to anchor people, people won't see the big picture (and you can't blame them).

          What troubles me about the system you described is it's not clear that there is a framework against which to define value. One tool that many of our clients like that provides this framework is a prioritization matrix. It's an excel spreadsheet that you put your criteria into and then judge your epics, features or projects against. This is a subjective method even through it will kick out a number :-) I can send you a copy if you'd like or you can download it from our website http://www.280group.com/resource-central/free-templates/feature-priority-matrix2/ but if you download it you'll get a lot more than just the matrix.

          -greg


          --- In scrumdevelopment@yahoogroups.com, "Whyves" <yvesriel@...> wrote:
          >
          > Thanks Greg,
          >
          > Unfortunately I will not make it to SQE but I hope to be able to get my hands on your presentation after the event!
          >
          > Does you presentation also say which one is most common in the industry? I want to bring a better way in my company to evaluate the BV of a Story/Epic.
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, "gregc" <greg@> wrote:
          > >
          > > Yves,
          > >
          > > On the off chance you will be at the SQE Better Software Conference West, I'll be presenting some strategies to use. But I prefer to use multiple lenses that highlight different elements of value and then piece together the whole. Some of these include:
          > >
          > > 1. Moscow
          > > 2. Kano
          > > 3. Time considerations
          > > 4. Sensitivity to time
          > > 5. Risk
          > > 6. Costs
          > > 7. Dependencies
          > > 8. Marketing considerations
          > >
          > > And we're talking prioritizing features/stories here. Before you even begin to go through this, you'll want to prioritize market segments, personas, and needs and understand the business's objectives.
          > >
          > > -greg
          > >
          > >
          > >
          > >
          > > --- In scrumdevelopment@yahoogroups.com, "Whyves" <yvesriel@> wrote:
          > > >
          > > > I would like to know what type of scale you are using regarding business values. My company is currently using the poker planning suite (1,2,3,5,8,13,20,40,100) for both the Story Points and the Business Value. I personally don't like this. It a very awkward way of doing this. I would prefer a more linear scale (1-10 or 1-100) or even a predefined list such as High-Medium-Low or the MoSCoW method.
          > > >
          > > > So, what is your opinion in this and what scale are you using?
          > > >
          > > > Thanks for your inputs!
          > > >
          > > > Yves
          > > >
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.