- When I m in this situation, I prefer to write the stories the way you described. Functionally, those other systems are the users of the sub-system you reMessage 1 of 40 , Dec 1, 2008View SourceWhen I'm in this situation, I prefer to write the stories the way you
described. Functionally, those other systems are the users of the
sub-system you're building.
Certified Scrum Coach
Founder and Principal Consultant, Humanizing Work, LLC
On Mon, Dec 1, 2008 at 9:10 AM, Mark Levison <mark@...> wrote:
> I'm sure this has been asked before - but after 20 minutes of digging I
> can't find the reference.
> One team team that I working with is building a backend component that
> suppports a number of other systems. I'm familiar with the idea that we
> shouldn't have component teams but rather feature teams
> (http://www.infoq.com/articles/scaling-lean-agile-feature-teams). However at
> the moment I can't help make that change, in addition the technology stack
> is deep enough that feature teams might not be enough.
> So my problem: How to write stories for backend components?
> In this case the product supports 4-5 other applications further up the
> stack than them (not all of which are end-user applications). So I'm
> wondering are stories written in the form:
> "The XXX application needs ..... for business reason" or do you find a way
> to write in terms of the actual end user even though this component doesn't
> work directly with end-users.
> Mark Levison
> Blog: http://www.notesfromatooluser.com/
> Recent Entries: Agile/Scrum Smells:
> Agile Games for Making Retrospectives Interesting:
- Hello, Roy. On Monday, December 8, 2008, at 11:03:21 PM, you ... Yes. I find that the exercise of expressing a technical story n terms of its business valueMessage 40 of 40 , Dec 9, 2008View SourceHello, Roy. On Monday, December 8, 2008, at 11:03:21 PM, you
> Ron, I was commenting on the debate that seemed to be about howYes. I find that the exercise of expressing a technical story n
> you write it down on a card. I did make the comment "I think the
> question is not if it should be a 'user story' or not, but who is
> responsible for paying for this? Is it part of the original
> project vision, that such components will be delivered as
> required, and is part of the project cost, or not?" which does
> encompass your concern (a quite correct concern, I agree).
terms of its business value is a very good one ... especially when
someone is trying to justify some techie thing that really doesn't
need to be done. :)
Of course that never happens ...
Find the simple path to what works and follow it,
always looking for a simpler path. -- Patrick D. Smith