Recommended Timebox for Release Planning?
Doug Shelton
Doug Shelton
eMail: Dshelt...@yahoo.com
Michael James
--mj
> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
Jan Beaver
In my experience, release planning works best when it is a continuous
activity rather than a time-boxed meeting. An initial release plan
consists of drawing a line under some portion of Product backlog,
marking the point at which the Product Owner believes sufficient
business value has been delivered. Since we're building a potentially
shippable product increment every Sprint, the PO can adjust the release
plan -- date and content -- as needed to meet business objectives. The
PO and team collaborate on the content and timing of the release plan,
but ultimately it is the PO's call.
If you need to have a broader stakeholder audience involved in deciding
on the initial release plan, by all means do so. If this meeting
requires the team to be present, pick a time box that is appropriate for
the planning activity, keeping in mind that the release plan might
change tomorrow.
Cheers,
Jan Beaver, PhD, CSP
Dan Rawsthorne
Ken wrote about it. It just popped up out of nowhere, and most of us
don't believe it's an intrinsic part of scrum. It's something projects
must do, butnot addressed in scrum, IMHO.
Dan Rawsthorne, PhD, CST
Senior Trainer/Coach, CollabNet
draws...@collab.net, 425-269-8628
Doug Shelton wrote:
> The Scrum Guide mentions that Release Planning is one of the
> time-boxed activities but doesn't give any guidelines (not could I
> find anything on Mr. Google) as to what that time increment should be,
> not even relative times. Any suggestions out there (and rationale for
> same)?
>
>
> *Doug Shelton*
>
> *eMail: *Dshelt...@yahoo.com <mailto:Dshelt...@yahoo.com>
Bachan Anand
The Scrum Guide mentions that Release Planning is one of the time-boxed activities but doesn't give any guidelines (not could I find anything on Mr. Google) as to what that time increment should be, not even relative times. Any suggestions out there (and rationale for same)?
We have used release planning effectively to make the team aware of the overall goal and vision of the project and also give the customer a macro level view of how we are making progress. Release planning can be used to answer questions like , "Which features are likely to be available for the trade show so that marketing can talk about it"
I don't believe it is necessary for every project and I have seen people not finding value in it especially when a team just start adopting Scrum and team velocity is not established, backlog items are still being moved around and additional features added. If a team is truly releasing potentially shippable software that get released to user at the end of every sprint , there will be less questions asked about release planning.
I have found it effective when done by the PO using the information that comes out of Sprint planning , Sprint Velocity ,Backlog grooming and story estimation and communicated to the team at the beginning of every or every other Sprint during the Sprint planning meetings.
So to summarize,
- not absolutely necessary
- minimal team involvement however leverage measure of truth that comes out from the team work.
- PO can do lot of this work,I have seen PO spending 1-2 hours/ Sprint.
- Communicate to the team every Sprint as part of Sprint planning.
- Communicate to everyone involved that things may change , this is what we know now and we will let you know more as we know more.