Am 16.04.2010 15:21, schrieb czrpb:
So let me try again (which of course may or may not be helpful!); and
start by taking back my statement: A "Milestone" is essentially a
feature. Very bad of me! grin! Also, if you have resources, eg. books,
links I ought to read and then return, that is a sufficient answer!
wink!
There's a couple of nice books - actually we create a 'Scrum Starter
Kit' which contains also a couple of books (you can buy them separately
of course):
http://www.agile42.com/cms/pages/scrum-starter-kit/
And yes, I think reading one or two scrum books (start with the Schwaber
book) will help you a lot in understanding. I'll try to add a few brief
answers.
But, we are not the only people on the team. There is another
Milestone called 'Automated Test Discovery' worked on by a couple of
other developers. They have 25 Tasks spread over 2 or 3 sprints.
Again, this is a Milestone because it is "big" and we want the
tracking. Like the Milestone above, I can release subsets of Tasks
that are useful to my users but are not the full 'Automated Test
Discovery' solution.
I understand your reasoning. However the basic thing here seems to be
'focus'. In Scrum you put together user visible features + internal
technical stuff in on the sprint. User stories are writting from a users
(customers) point of view only!
So the work you're doing within a sprint, just contributes to a release
and there are no parallel "streams" - everything is focused on
delivering value for the customer!
Now, we/I are/am probably not very Scrum'ish, but User Stories would
just be another level of hierarchy and only within sprints. We ignore
User Stories and mostly just use Tasks it seems. This means often one
or more of our Tasks are User Stories; but I can not see how adding a
User Story would help us.
It's about getting work *done* - so a feature is completed and ready for
release. So the user does not care about tasks (basically small
developer work packages from 1h-2days) but real features.
By having user stories, you can track the progress of each 'feature'.
On a higher level you group multiple sprints to milestones to track
progress on a higher level (e.g. a two-week basis, important for the
product owner). A task can be done by one or more persons, all
collaborating to get one user story done.
In the whiteboard all tasks for one story are grouped together so you
can see the progress easily.
(Example: When we add to our backlog we tend
to say something like: Oh! We need to do X. And to do X I need to do
Tasks T1, T2, and T3. We add the Tasks to the Backlog and pretty much
never create the User Story associated; and we are likely unclear on
the Scrum way and therefore misunderstanding that User Stories are not
useful to us.)
This should be detected during the sprint planning meeting or even
before when developers look at user stories and create a 'implementation
plan' (even just by talking to each other).
HTH
fs
--
Follow Agilo on Twitter: http://twitter.com/agiloforscrum
-----
You received this message because you are subscribed to the Google
Groups "Agilo for Scrum" group. This group is moderated by agile42 GmbH
http://www.agile42.com and is focused in supporting Agilo for Scrum users.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/agilo?hl=en
