RE: Sprint backlog display confused
Eirik Pettersen
Just following up on your email - it is very helpful, and self
explanatory.
Here's why I thought what I thought:
> -----Original Message-----
> From: Andrea Tomasini [mailto:andrea....@agile42.com]
> Sent: 15 June 2008 14:22
> To: Eirik Pettersen
> Cc: suppor...@agile42.com; Development
> Subject: Re: Sprint backlog display confused
>
>
> On 9 Jun, 2008, at 18:32 , Eirik Pettersen wrote:
>
> Hi Eirik,
> sorry for the late reply, but was not ranked has bug this time ;-)
>
> > PS: Do you have any documentation on how you agilo fits in to the
> > process of turning the business ideas in to tasks? I've been trying
> > to
> > reverse engineer the reports and the config in the VM, and my guess
is
> > as follows:
> >
> > 1. Collect ideas (into 'idea' tickets)
> That's right, some customers actually use the WiKi for Ideas, Vision,
> Concept, and than within the page the link to requirements that refers
> to the idea. A good tip here could be to model requirements,
> eventually use some property as idea or theme or whatever you want,
> and via dynamic Query Macro, show the requirements matching the
> specific theme or idea into the idea Wiki Page ;-) So you will have a
> dynamic report, showing also the status of the requirements.
>
> > 2. Convert ideas into business requirements
> More than convert I would use break-down, in fact what normally
> happens you try to schematize high level concept into a set of "bullet
> points" and these are refined into SMART requirements ;-)
>
> > 3. Convert requirements into user stories
> Again I would say break-down, requirements are more representing the
> WHAT and WHY, and are still at a Business Level, good thing where to
> stick a Business Value, and right granularity for stakeholders. User
> Stories are more representing the HOW you want to fulfil a requirement
> in terms of Product Features, or interaction between user and product/
> system (At each release cycle you could do a Story Workshop)
>
> > 4. Pick out user stories and break into tasks
> Right, this is normally done only at the Sprint Planning Meeting,
> second part, after initial estimation in story points and initial
> commitment has been done.
>
> > 5. Complete tasks, thus user stories, in an iteration.
> right, tasks can anyway continuously change, new found and re-planned,
> according to the team findings...
>
> > 6. Iterate until a set of requirements are delivered for a release
> The requirements are normally set as the release Goal, and you break
> down into detailed pieces so to monitor and "drive" the release
> requirements completion. There are many leverages with which the PO
> can control these achievents ;-)
>
> > I am not sure how 'bugs' fit into the picture, nor how the link
> > 'bug-story' should go. We're considering a bug to be a special form
> > of
> > a user story ticket, and is picked out of the backlog like user
> > stories,
> > the points are estimated and it's in turn broken into tasks. Also,
> > we've added this troublesome 'requirement to user stories' link so
we
> > can bunch them together in the backlog view.
> Bugs are "tickets" like any other, the difference we normally make is
> that if a Bug is classified as Blocking or Critical, than has to be
> planned into the iteration. The link Bug->User Story helps in keeping
> trace of the original specification and eventually being able to use
> it for statistics purposes, eg: sum up the time spent in fixing bug
> and the initial development time of a story to calculate its cost, or
> simply calculate the efficiency of development and the overall quality
> of the Software. Bugs can come for a production version, or from the
> current product development, and if are not Blocking or Critical have
> to be planned like any other Backlog Items, they do indeed have a
> business value too... that you can measure as Retainment (of existing
> customers) or Operational Efficiency (in case you have to Work Around
> a lot of things...)
>
> > Is this how you see the tool being used?
> More or less I would say you got it ;-) Point is that there are many
> way of making Scrum, the Goal of our tool, because we believe in the
> Agile Paradigm is to bring people together, and maximize full-
> bandwidth communication, is to support as much as possible the Scrum
> Cerimonies, crucial decision moment in Scrum :-)
>
> HTH
> Best
> ANdreaT
Andrea Tomasini
On 23 Jun, 2008, at 16:52 , Eirik Pettersen wrote:
> Hi Andrea
Hi Eirik,
> Just following up on your email - it is very helpful, and self
> explanatory.
Nice to hear from you :-)
> Here's why I thought what I thought:
I guess there's a piece missing here :-)
Best
ANdreaT
P.S: Now we are mirroring support to the newly opened Google Group, so
in case you want to discuss private things, please write to personal
address