Sprints and Milestones

[Dan]

I'm a bit confused about how sprints and milestones should work
together in 0.7. I created a few test stories with tasks and a few
sprints and assigned the stories to one of my sprints. That sprint in
turn is assigned to a milestone. I expect this to be useful for
assigning sprints to releases (we have releases that include one or
multiple sprints).

I'd like to see a list of all tickets in a milestone or in a sprint
assigned to that milestone (i.e. what changes are in this release?)

But when I view tickets in that milestone I don't see any:

http://tinypic.com/view.php?pic=16m3ajn&s=4

Also, as you can see here, if I attempt to filter a custom query by
Sprint, I don't see my sprints in the pulldown.

How is this intended to work? Is there a right way to see all
changes (all tasks left to complete, or all bugs to verify, etc.) in a
release (milestone) in your system?

- Dan

[ANdreaT]

>   I'm a bit confused about how sprints and milestones should work
> together in 0.7.  I created a few test stories with tasks and a few
> sprints and assigned the stories to one of my sprints.  That sprint in
> turn is assigned to a milestone.  I expect this to be useful for
> assigning sprints to releases (we have releases that include one or
> multiple sprints).

That's the reason why we made Sprint as a separate object, the fact
that is not yet bound to the Milestone in a proper way, is because we
didn't implement that feature yet, at the moment is just a separate
object that can be created as a "step" to reach a milestone that
should be than used for releases. The idea behind is the same you
have, which for us makes more than sense, plus the fact that we would
like to give the Product Owner the possibility to plan releases by
assigning requirements to the milestone, and than see it broken down
into the sprints as User Stories, so that the PO will plan by value,
and will try manage expectations based on teams velocities and
achievements one sprint after the next :-) What do you think?

>   I'd like to see a list of all tickets in a milestone or in a sprint
> assigned to that milestone (i.e. what changes are in this release?)

That should be in the next build, I am already working on that... I am
not sure I will include the changes to integrate it into the standard
Trac report, but I'll do my best. For sure will be integrated in the
Backlog, that means you can make a "milestone" scoped backlog that
will contains also all the tickets belonging to the Sprints of that
milestone.

>   Also, as you can see here, if I attempt to filter a custom query by
> Sprint, I don't see my sprints in the pulldown.

That is a change we will have to make to the report module of Trac,
the one linked to View Tickets... it is not as easy as it seems... :-(

>   - Dan
ANdreaT

[Dan]

I see. It sounds like you're going in the direction I'd expect.
I'd like to be able to group user stories (and thus tasks) into
sprints and sprints into milestones for release / integration. But
the most important benefits of this are the two reports I mentioned -
including tickets assigned to the milestone itself or any sprint
assigned to that milestone. (If I could filter by sprint in the
custom query I could easily narrow that down to one sprint or no
sprint.)

- Dan

[ANdreaT]

Ok, what is implemented so far:

- You can create a "milestone" scoped backlog (Release Backlog) that
will contain all the ticket planned explicitly for the milestone
(typically meant to be requirements planned by the PO in terms of
Release Goals) and all the ticket planned in every Sprint belonging to
the milestone.
- Working now on integrating the Sprint concept into the Custom Query
and the Report of Trac, may be I found a tricksy and easy way to do
that ;-)

One questions though, what behaviour you would expect in case you
would like to remove a ticket from a "milestone" scoped Backlog? In
case the ticket is in the Backlog, but indeed is planned for a Sprint,
would you like to remove it only from the Release Backlog or also from
the Sprint Backlog, or simply be notified or see that that ticket is a
derived ticket is not directly planned in the release, but in one of
its sprint?

We had a discussion on this yesterday and we are pretty much convinced
that the best way is to inform that the ticket is planned in the
Sprint, and if you don't want to see it in the Release Backlog (I see
no reason why you should, but we are open minded) than you will have
to remove it from the Sprint as well (Transparency and consistency are
the drivers).

What do you think?

Best
ANdreaT