Re: [scrumdevelopment] where do development type stories go?
- On Tue, 05 Oct 2004 16:29:41 -0700, todd <todd@...> wrote:
> In the BigMoneyJobs example it is said something like "use a databaseOne thing I look for is to link the technical thing with something the
> connection pool"
> isn't a valid user story. That makes sense as users fortunately can be
> ignorant of connection pools. My question is where does this type
> of story go and how does it figure into the schedule? Deciding on which
> connection pool to use requires some effort.
user values. In this case, it could be "Lower database license costs"
or "Improve search performance" etc. Once it's in the customer's
language, they can understand why they want such a thing. ("Do some
techie thing I don't understand" vs. "Save big $$$").
(The other thing here is that when you start framing things this way,
you may find there are a lot of different things that might accomplish
> Along similar lines, where did all the work go in figuring out whatI prefer "deliver feature" stories to "plan/research" stories, but
> technologies BigMoneyJobs
> would use? Is it jsp/.net/c++/html/CGI/asp/tomcat etc? Where are
> questions like where will the system be hosted, how will it be managed,
> backedup, etc handled?
sometimes you have the latter. The customer often (and I think
management always) has some stake in these decisions: they're paying
to support them for the long term, etc. For example, you might have a
research story that looks into the cost of availability, and comes
back with options: "99% availability for $xxxx, 99.999 for $xxxxxx,
99.999999 for $xxxxxxxxxxxx". I'm just careful that the developers
don't take such a question as an excuse for a 6-month research study.
Sometimes a customer will need some education, or exposure to the
right stakeholder, but in general they know that things they want have
a cost. And it's ok for the developers to make a strong pitch for what
they want; the customer can take that into account too.
> My knowledge of scrum is recent, so i may be reaching here, but itWell, Scrum certainly doesn't require the story approach. But since
> seems like
> these are legitimate items to put in the product backlog or sprint backlog.
the product owner prioritizes the product backlog, things on it need
to make sense to them. For the sprint backlog, that's explicitly owned
by the technical team and will often have tasks in developers'
> Perhaps this is different than XP, but the scrum backlog items are notRight. XP has the release plan containing stories, and the iteration
> to stories. The sprint backlog, at least, is for the development team so it
> definitely can contain programming centered tasks.
plan containing tasks. Scrum has the product backlog, that the product
owner controls, and the sprint backlog, that the team controls.
They're sort of on two different dimensions, but the end result is
pretty close to the same.
Bill Wake William.Wake@... www.xp123.com
- Ken's CSM course does cover Scrum pre-project steps - at different
levels of detail for different situations: New Unfunded Projects, New
Funded Projects, Ongoing Projects, Fixed Price/Fixed Date Projects. In
my copy of the methodology book, these are grouped under the title
"planning" which occurs before the first Sprint Planning meeting.
> On Thu, 07 Oct 2004 12:22:32 -0700, todd <todd@p...> wrote:lack
> > The lack of a pre-project phase in all the methodologies is major
> > in my mind.
> I would not say this is true of Jim Highsmith's APM. Do others agree
> or have a different view?
> This could be an interesting discussion thread in its own right. What
> do you do wtih the work before a project starts or is funded?
> Alistair Cockburn
> President, Humans and Technology
> Phone: 801.582-3162
> 1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
> _mailto_ (http://mailto/) : acockburn@a...
> _http://alistair.cockburn.us/_ (http://alistair.cockburn.us/)
> Author of
> "Surviving Object-Oriented Projects" (1998)
> "Writing Effective Use Cases" (Jolt Productivity Award 2001)
> "Agile Software Development" (Jolt Productivity Award 2002)
> "La perfection est atteinte non quand il ne reste rien a ajouter,
> mais quand il ne reste rien a enlever." (Saint-Exupery)