Re: [scrumdevelopment] More newbie questions...
- On Friday, August 1, 2003, at 1:20:32 PM, nasapatrick wrote:
> Okay, so I have a backlog item like -- Derive the universe, use backI'd break it up, make it smaller. One advantage to this is that lots of the
> of paper as necessary -- Well, not that bad. But say your backlog
> item is a very large task like build a graphing tool that can display
> graphs of all resource types, task types and availabilities from the
> data source.
> Which do you do?
> - Break it into many product backlog items?
> - Choose a sprint goal to implement only part of a backlog item?
> As I understand it, we don't want to get into the old practice of
> writing hundreds of traditional requirement shalls. But if the team
> doesn't finish a backlog item, then you update the backload to
> say "graph all types except the one we finished last sprint."
> I know, I know... I am definitely a newbie on running project.
subparts (make sure universe supports life) are much more important, and
some are less so (make lizards have hair).
That's how we got where we are. Each of six sprints, just one simple task
per sprint. And on the seventh sprint, He shipped it. If breaking it down
was good enough for Him, it's good enough for me.
Wisdom begins when we discover the difference between
"That makes no sense" and "I don't understand". --Mary Doria Russell
> From: "Christian Knott" <chrisknott@...>Christian:
> With Scrum, we get to show what's been done every 30 days. That means
> that the "alignment smell" gets to be put on view once a month
> instead of, well, never in many other cases.
But in Scrum we also show what is done every day. Remember,
"Daily Build" and "Daily Scrum" are basic Scrum patterns.
A while ago Jeff Sutherland pointed to an article written by
Martin Fowler about continuous integration. All good and dandy.
It is great to have things like Anthill produce automatic builds
and run batches of unit tests. But it is also important for
the Customer to interact with stable versions of the application
and give feedback from hands-on experience on a daily basis.
Also, there are things like Fit and Fitnesse that attempt to
Automate "acceptance testing". Our style is to do this
through "human interaction" -- there are some things that
we feel are best leaving non-automated i.e. where we want humans
In our development we have perhaps hundreds if not thousands
of builds every day, and thousands of check ins and updates,
but we advertise at least one stable build daily for the customers
to play with.
> For the specific problem of fuzzily defined requirements for reports,done.
> I'm with Ron, pretty much. My difference: do something. Anything.
> Guestimate what the report should be, do it quickly, then mark it
Well, "mark it done" might be pushing your luck.
Some customers take it very offensively to "mark things done"
if they are not done. But certainly, getting a report out
for someone to see will start the feedback loops. (Don't forget
to update your daily estimate to completion after some work
and feedback are produced :-)
> The donors/owners will soon start griping, and you can convertTrue.
> their gripes into requirements that go on the product backlog.