Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Release Planning when team composition might vary

Expand Messages
  • D.AndrĂ© Dhondt
    ... Normally we only estimate one week s worth of story cards--so the release plan has un-estimated epics to remind us to talk about that subject later. -- D.
    Message 1 of 3 , May 14, 2011
      On Tue, May 10, 2011 at 10:36 AM, Ajithesh Hegde <ajithesh.gh@...>wrote:

      > Just to elaborate my question:
      > 1. Release Planning is done based on the story point estimates (for the
      > user
      > stories) and the team velocity expressed in story points.
      >

      Normally we only estimate one week's worth of story cards--so the release
      plan has un-estimated epics to remind us to talk about that subject later.

      --
      D. André Dhondt
      mobile: 215-805-0819
      skype: d.andre.dhondt
      twitter: adhondt http://dhondtsayitsagile.blogspot.com/

      Support low-cost conferences -- http://AgileTour.org/
      If you're in the area, join Agile Philly http://www.AgilePhilly.com


      [Non-text portions of this message have been removed]
    • Joshua Kerievsky
      ... Consider making a Release Plan filled with critical features (i.e. remove all nice-to-have functionality), represented as user story cards. Roughly
      Message 2 of 3 , May 14, 2011
        On Tue, May 10, 2011 at 7:36 AM, Ajithesh Hegde <ajithesh.gh@...>wrote:

        > Wish to know how you do Release Planning if the team composition is to
        > vary
        > in different iterations.
        >

        Consider making a Release Plan filled with critical features (i.e. remove
        all nice-to-have functionality), represented as user story cards. Roughly
        estimate each release story card (you can use estimates of weeks -- 1 week,
        2 weeks, etc) given the team you have today. Re-estimate each release story
        card every iteration (I call this iterative release planning) and do some
        rough accounting to see that the time remaining will fit the estimated work.
        If there is too much work, defer stuff or find ways to do expensive work in
        a less-expensive, faster way (e.g. by providing 80% of the functionality).
        Keep exploring what functionality can be removed and what functionality is
        essential to producing a minimum viable product. Report the evolving
        release plan to management, highlighting possible risks and how they are
        being managed.

        --
        best,
        jk

        --
        Joshua Kerievsky
        Founder, CEO
        Industrial Logic, Inc.
        Web: http://industriallogic.com
        Twitter: @JoshuaKerievsky, @IndustrialLogic

        Amplify Your Agility
        Coaching | Training | Assessment | eLearning


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.