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

2944RE: Re: [scrumdevelopment] Developer's requirements

Expand Messages
  • Mike Beedle
    Mar 10, 2004

      I like your list but I would add:

      Revenue - will it generate sales, revenue
      and/or profits?

      and modify this one:

      Legislative - is it a legal requirement?

      What are my chanced or getting fined,
      have a media exposure, or being prevented
      from market opportunities if I break the Law?

      In many cases, as much as it is cumbersome to say,
      it "costs less to break the law",

      - Mike


      "Nothing in the world is so powerful as an idea whose
      time has come."
      --Victor Hugo

      From: dave@...
      Sent: Wednesday, March 10, 2004 4:07 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: Re: [scrumdevelopment] Developer's requirements

      In my view, it's all about "justification".

      We justify any requirement for at least one of:
      Cost - will it save money?
      Qualitative - will it improve the quality of the product?
      Legislative - is it a legal requirement?

      If you can't justify the change (technical or not) in any of the above -
      it's just a whim.

      Dave Hostick

      > Message date : Mar 10 2004, 01:23 AM
      > From : "Ron Jeffries" <ronjeffries@...>
      > To : scrumdevelopment@yahoogroups.com
      > Copy to :
      > Subject : Re: [scrumdevelopment] Developer's requirements
      > <html><body>
      > <tt>
      > On Tuesday, March 9, 2004, at 12:15:16 PM, Claude Montpetit wrote:<BR>

      > <BR>
      > > I am starting to implement Scrum on small team of around 5
      > > developers.<BR> One of the challenge here is to move the
      > > responsibility of assigning<BR> priorities out of the development
      > > team and give it to a<BR> marketing/product-management
      > > representative (the product owner in the<BR> context of Scrum). The
      > > development team is used to have full control<BR> on what direction
      > > the product takes and which area of the product<BR> requires the
      > > biggest effort.<BR>
      > <BR>
      > > So the first problem I encountered was dealing with technical tasks
      > > or<BR> stories originating from the development team, tasks that
      > > have no<BR> apparent value to the product owner, but still appear as

      > > the highest<BR> priority to the dev team. For example:<BR>
      > <BR>
      > > - "We need to change the entire CVS structure to facilitate the
      > > build<BR> and upgrade managenement process."<BR>
      > <BR>
      > > Does this task enter the product backlog as is? Or should it be<BR>

      > > reformulated in a way that the product owner sees value in it?
      > > For<BR> example, the developer could enter the following story
      > > instead:<BR>
      > <BR>
      > > - "We need to facilitate the upgrade process of our client<BR>
      > > installations. Currently, customers must uninstall the current
      > > version<BR> and install a new one. We need an incremental upgrade
      > > process."<BR>
      > <BR>
      > It is my opinion that no work should be done unless its business value

      > to<BR> the product and the Product Owner can be identified.<BR> <BR>
      > In this case, if the customer is happy uninstalling, then he should
      > schedule the story, and the team should not do it. In my opinion,
      > course.<BR>
      > <BR>
      > > Then, when this task enters a sprint, one of the task that the
      > > dev<BR> team can add to implement this is the one described above
      > > CVS task.<BR>
      > <BR>
      > > So the question is whether the members of development team should
      > > try<BR> to convert their technical tasks or stories into requests
      > > where the<BR> client sees value? Is it always possible to do so? Or
      > > is there times<BR> when the development team should "convince" the
      > > product owner that a<BR> technical story must be prioritized as
      > > high?<BR>
      > <BR>
      > In all the cases I have seen, if a technical "story" should be
      > prioritized<BR> high, there is a business purpose behind it which the
      > customer can sign up<BR> for. If the customer cannot, conversely, I
      > think the story is probably not<BR> high after all, or not well
      > understood.<BR> <BR>
      > > "Believe us, you want to set this as a high priority story
      > > man!"<BR>
      > <BR>
      > "I'm paying for this stuff. Put it in terms of my interests."<BR> <BR>
      > Ron Jeffries<BR>
      > www.XProgramming.com<BR>
      > It's easy to have a complicated idea. It's very very hard to have a
      simple idea.<BR>
      > -- Carver Mead<BR>
      > <BR>
      > </tt>
      > <br><br>
      > <tt>
      > To Post a message, send it to: scrumdevelopment@...<BR>
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...</tt>
      > <br><br>
      > <!-- |**|begin egp html banner|**| -->
      > <br>
      > <tt><hr width="500">
      > <b>Yahoo! Groups Links</b><br>
      > <ul>
      > <li>To visit your group on the web, go to:<br><a
      > <li>To unsubscribe from this group, send an email to:<br><a
      > <li>Your use of Yahoo! Groups is subject to the <a
      href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.
      > </ul>
      > </tt>
      > </br>
      > <!-- |**|end egp html banner|**| -->
      > </body></html>
      Freeserve AnyTime - HALF PRICE for the first 3 months - Save £7.50 a

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Yahoo! Groups Links

      To visit your group on the web, go to:

      To unsubscribe from this group, send an email to:

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Show all 7 messages in this topic