I completely agree and second this - along with the other posts that have
voiced similar concerns. For me the current problem is that we finished some
stuff we weren't expecting to release until a larger requirement was done. But
after demoing the completed tasks, the product owner decided it was a good idea
to release what we had but hold off on the larger requirement because he wanted
to add a few things to it yet. Now, I can't separate out this work into a new
sprint because if I modify the milestone, it deletes the sprint association.
So, even though I completed story X in sprint 10 (which was associated with a
milestone "Release 2.2"), if I move it to milestone "Release 2.3", sprint 10
gets deleted because it's not associated with that milestone.
It's been very annoying and frustrating. For now I've decided to generalize my
milestones to be timeframes ("Mid-July") and then I'm using the "version" field
to keep track of versions. What's frustrating is that we do two week sprints
and might find value in releasing some of the bug fixes and such that were
done, but I can't get that specific in my milestones because there's a
one-to-one relationship with sprints and milestones.
Anyway, I can understand the theory - but in practice it does seem very
limiting when you have a lot of stuff being fulfilled and you can't really
manage it as you think you should be able to.
Ryan
On Jun 15, 2010, at 11:06 AM, Manni wrote:
> I know similar posts haven been made before, but let me add a slightly
> different perspective.
>
> 1) Sprints have to be associated with a milestone. I cannot even
> create a sprint without specifying which milestone it should belong
> to. 2) Stories are associated with sprints. Therefore, each story in a
> sprint is also associated with a milestone.
>
> In effect, this means that I cannot have a sprint in which work is
> done that belongs to two different milestones. I cannot, e.g., start
> work on feature X that is supposed to be released in October, if in
> that same sprint, I'd also like to finish work on feature Y that will
> be released in August.
>
> Maybe this is not a common situation, but for us it is the norm. So
> what we end up doing is that we define milestones that are completely
> meaningless, just because we need some sort of milestone to create
> sprints.
>
> So what I would like to suggest is this: disassociate milestones and
> sprints. Since requirements can be tied to milestones and stories are
> tied to requirements, the work for each milestone is documented along
> with those stories and there is no need to force sprints into
> milestones.
>
> --
> Follow Agilo on Twitter: http://twitter.com/agiloforscrum
> Please support us by reviewing and voting on:
> http://userstories.com/products/8-agilo-for-scrum
> http://ohloh.net/p/agilo-scrum
> http://freshmeat.net/projects/agiloforscrum
>
> You have received this message because you are subscribed to
> the "Agilo for Scrum" Google Group. This group is focused on
> supporting Agilo for Scrum users and is moderated by
> agile42 GmbH <http://www.agile42.com>.
>
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send an email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/agilo
Ryan Booz
Chief Information Officer
EnergyCAP, Inc.
phone: 877.327.3702 x26
cell: 814.574.2965
fax: 719.623.0577
[email protected]
EnergyCAP®—Measure, Manage, SaveTM on 50 or more Utility Bills
--
Follow Agilo on Twitter: http://twitter.com/agiloforscrum
Please support us by reviewing and voting on:
http://userstories.com/products/8-agilo-for-scrum
http://ohloh.net/p/agilo-scrum
http://freshmeat.net/projects/agiloforscrum
You have received this message because you are subscribed to
the "Agilo for Scrum" Google Group. This group is focused on
supporting Agilo for Scrum users and is moderated by
agile42 GmbH <http://www.agile42.com>.
To post to this group, send email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/agilo
