2944RE: Re: [scrumdevelopment] Developer's requirements
- Mar 10, 2004Dave,
I like your list but I would add:
Revenue - will it generate sales, revenue
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",
"Nothing in the world is so powerful as an idea whose
time has come."
Sent: Wednesday, March 10, 2004 4:07 AM
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.
> Message date : Mar 10 2004, 01:23 AMnot<BR>
> From : "Ron Jeffries" <ronjeffries@...>
> To : firstname.lastname@example.org
> Copy to :
> Subject : Re: [scrumdevelopment] Developer's requirements
> On Tuesday, March 9, 2004, at 12:15:16 PM, Claude Montpetit wrote:<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>
> > 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>
> > - "We need to change the entire CVS structure to facilitate the
> > build<BR> and upgrade managenement process."<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>
> > - "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>
> 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,of<BR>
> course.<BR>simple idea.<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>
> > 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>
> 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>
> "I'm paying for this stuff. Put it in terms of my interests."<BR> <BR>
> Ron Jeffries<BR>
> It's easy to have a complicated idea. It's very very hard to have a
> -- Carver Mead<BR>href="http://groups.yahoo.com/group/scrumdevelopment/">http://groups.yah
> To Post a message, send it to: scrumdevelopment@...<BR>
> To Unsubscribe, send a blank message to:
> <!-- |**|begin egp html banner|**| -->
> <tt><hr width="500">
> <b>Yahoo! Groups Links</b><br>
> <li>To visit your group on the web, go to:<br><a
> <li>To unsubscribe from this group, send an email to:<br><ahref="mailto:email@example.com?subject=Unsubs
> <li>Your use of Yahoo! Groups is subject to the <ahref="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.
> </ul>Freeserve AnyTime - HALF PRICE for the first 3 months - Save £7.50 a
> <!-- |**|end egp html banner|**| -->
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.
- << Previous post in topic Next post in topic >>