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

Re: Scrum Planning and Promotion Activities

Expand Messages
  • karikday
    Hi Howard, From the CSM class, we were taught that there are two types of planning - scrum planning and sprint planning. Scrum planning involves the
    Message 1 of 6 , Oct 3, 2007
    • 0 Attachment
      Hi Howard,
      From the CSM class, we were taught that there are two types of
      planning - scrum planning and sprint planning. Scrum planning
      involves the activities required to produce a healthy product backlog.
      Depending on the initiative, this could be a day or a week. Sprint
      planning is the quick planning sessions that take place as part of
      every sprint - ending with a healthy sprint backlog.

      We have talked about this as a team and as I've said, haven't come up
      with anything that really works well. So just to be clear, I'm not
      talking about sprint planning - those activities are very clear,
      defined and focused. Coordinating all of the activities to get a
      project together and a healthy product backlog...not so much.

      During the same course, we were taught that at the end of each sprint
      the customer can choose to promote the completed work to "production".
      Again we've tried a few different ways of tracking the work that
      needs to be done to promote. Again, we're just looking to hear what
      others are doing. What we had been doing most often was stop, have a
      special sprint specifically for promotion activities, then get back to
      our normal development/testing sprints afterward. Our promotion
      process may be more/less complex than other companies, so we may not
      be able to leverage that much...but are still interested.

      --- In scrumdevelopment@yahoogroups.com, Hubert Smits
      <hubert.smits@...> wrote:
      >
      > Hey KD,
      >
      > It feels like you're trying to organize the events, I would ask the
      team the questions you are asking here. They have to invent the
      practices that work, self-organize. It also feels that your planning
      event is rather long, how much time do you spend in Sprint planning. I
      see events which take 3 or 4 hours. And what is the promotion stage
      you mention, I never came across this term.
      >
      > --Hubert
      >
      > karikday <karikday@...> wrote: We continue to struggle with activity
      tracking during "Scrum
      > Planning" and "Promotion". I realize that every company has
      > different planning, promotion procedures and timeframes, however,
      > I'd be interested in hearing whether others are using to track the
      > activities that take place during these timeframes.
      >
      > During Scrum Planning there are activities other than story writing
      > workshops, such as vendor coordination, job shadowing, business
      > process discovery, scrum overview/coaching for new team members,
      > etc. During promotion, much less various tasks occur, but tasks none
      > the less. The sprint backlog works so well for sprints that we
      > thought we'd try to use them for these activities too - and it just
      > didn't work out as well as we thought. Primarily because there are a
      > bunch of discovery activities the IT team needs to have with the
      > customer to get our arms around their business need and current
      > process. We're not really concerned about team capacity or hours
      > left - more about getting the activities done at the best times. Our
      > focus is to learn as much as we can before having the official "story
      > writing workshops". Examples could be "Model existing business
      > process", "Talk with network team about what's required to publish a
      > secured web service", "Find out what the customer means when they say
      > the current system doesn't always work ;)", "Review vendor
      > specification information", etc. We feel we absolutely have to this
      > planning in order to effectively story point.
      >
      > Also, what luck have you had with stand up meetings during these
      > timeframes? We feel it's essential for team communication to have
      > stand ups during planning, sprints, and promotion. However, without
      > a snappy way of activity planning, they aren't nearly as effective
      > and focused as our sprint stand ups. They almost remind me of the
      > stand ups we had before we starting using the sprint backlog - vague
      > and not effective in indicating whether you're getting closer to your
      > goal.
      >
      > I'd love to hear what others may be doing - or not doing. If you've
      > found an inspiring article or whitepaper - please share.
      >
      > Thanks,
      > KD
      >
      >
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
    • Hubert Smits
      Hi KD, I think you were addressing me, although it has been a while since I went by the name Howard :-) If I understand you right then you have a question
      Message 2 of 6 , Oct 3, 2007
      • 0 Attachment
        Hi KD,

        I think you were addressing me, although it has been a while since I went by the name Howard :-)

        If I understand you right then you have a question around preparing the backlog, and around the go-live process.

        Backlog preparation: I've not heard of the term Scrum Planning, but the concept makes sense. The product owner and the people around him (hopefully an architect, some dev and qa people) have to translate the vision into features/stories. I advise to run a sprint for it, so the activity is timeboxed, has stand-ups etc. And I advise not to spend too much time, a backlog is never right, never done, can always be corrected. So start building and demonstrating results as soon as possible. The feedback loop that you create this way will improve your backlog and improve the product. If your product is complex, all new technology, new architecture then you may need a Sprint Zero - proving the architecture to work with real features. A well functioning team of product owner / architect should be able to merge the Scrum Planning with the Sprint Zero concept. It is not easy though, expect to fail and learn, it is a lot more productive then a year of design and architecture work though.

        Releasing to production: for new teams a hardening sprint (the concept you describe) is often needed to 'go live', there is work that doesn't seem to fit in a Sprint. Don't forget the 'art of the possible' to continuously improve on what doesn't seem to fit. It doesn't all happen in 3 or 6 months. The largest company that I worked with took 14 months to crack this nut, and another 6 to become best in class (according to Cutter). A lot of hard work, discussions, and technology improvements were needed. And now they deliver shippable software every month.

        Hope this helps, let me know where you're specifically struggling.

        --Hubert

        karikday <karikday@...> wrote:
        Hi Howard,
        From the CSM class, we were taught that there are two types of
        planning - scrum planning and sprint planning. Scrum planning
        involves the activities required to produce a healthy product backlog.
        Depending on the initiative, this could be a day or a week. Sprint
        planning is the quick planning sessions that take place as part of
        every sprint - ending with a healthy sprint backlog.

        We have talked about this as a team and as I've said, haven't come up
        with anything that really works well. So just to be clear, I'm not
        talking about sprint planning - those activities are very clear,
        defined and focused. Coordinating all of the activities to get a
        project together and a healthy product backlog...not so much.

        During the same course, we were taught that at the end of each sprint
        the customer can choose to promote the completed work to "production".
        Again we've tried a few different ways of tracking the work that
        needs to be done to promote. Again, we're just looking to hear what
        others are doing. What we had been doing most often was stop, have a
        special sprint specifically for promotion activities, then get back to
        our normal development/testing sprints afterward. Our promotion
        process may be more/less complex than other companies, so we may not
        be able to leverage that much...but are still interested.

        --- In scrumdevelopment@yahoogroups.com, Hubert Smits
        wrote:
        >
        > Hey KD,
        >
        > It feels like you're trying to organize the events, I would ask the
        team the questions you are asking here. They have to invent the
        practices that work, self-organize. It also feels that your planning
        event is rather long, how much time do you spend in Sprint planning. I
        see events which take 3 or 4 hours. And what is the promotion stage
        you mention, I never came across this term.
        >
        > --Hubert
        >
        > karikday wrote: We continue to struggle with activity
        tracking during "Scrum
        > Planning" and "Promotion". I realize that every company has
        > different planning, promotion procedures and timeframes, however,
        > I'd be interested in hearing whether others are using to track the
        > activities that take place during these timeframes.
        >
        > During Scrum Planning there are activities other than story writing
        > workshops, such as vendor coordination, job shadowing, business
        > process discovery, scrum overview/coaching for new team members,
        > etc. During promotion, much less various tasks occur, but tasks none
        > the less. The sprint backlog works so well for sprints that we
        > thought we'd try to use them for these activities too - and it just
        > didn't work out as well as we thought. Primarily because there are a
        > bunch of discovery activities the IT team needs to have with the
        > customer to get our arms around their business need and current
        > process. We're not really concerned about team capacity or hours
        > left - more about getting the activities done at the best times. Our
        > focus is to learn as much as we can before having the official "story
        > writing workshops". Examples could be "Model existing business
        > process", "Talk with network team about what's required to publish a
        > secured web service", "Find out what the customer means when they say
        > the current system doesn't always work ;)", "Review vendor
        > specification information", etc. We feel we absolutely have to this
        > planning in order to effectively story point.
        >
        > Also, what luck have you had with stand up meetings during these
        > timeframes? We feel it's essential for team communication to have
        > stand ups during planning, sprints, and promotion. However, without
        > a snappy way of activity planning, they aren't nearly as effective
        > and focused as our sprint stand ups. They almost remind me of the
        > stand ups we had before we starting using the sprint backlog - vague
        > and not effective in indicating whether you're getting closer to your
        > goal.
        >
        > I'd love to hear what others may be doing - or not doing. If you've
        > found an inspiring article or whitepaper - please share.
        >
        > Thanks,
        > KD
        >
        >
        >
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >




        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
        http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
        Individual Email | Traditional

        <*> To change settings online go to:
        http://groups.yahoo.com/group/scrumdevelopment/join
        (Yahoo! ID required)

        <*> To change settings via email:
        mailto:scrumdevelopment-digest@yahoogroups.com
        mailto:scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
        scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
        http://docs.yahoo.com/info/terms/


      • Peter Borsella
        Hi, All, Scrum Planning is a term that I use in CSM training. Bryan Stallings and I created this term a couple of years ago to describe any and all
        Message 3 of 6 , Oct 4, 2007
        • 0 Attachment
          Hi, All,

          "Scrum Planning" is a term that I use in CSM training. Bryan
          Stallings and I created this term a couple of years ago to describe
          any and all activities that an organization must go through before
          launching a Scrum Team against a project. Some choose to integrate or
          interchange this term with Sprint Zero, Release Planning, etc.

          I hope this clarifies.

          ...Peter Borsella

          --- In scrumdevelopment@yahoogroups.com, Hubert Smits
          <hubert.smits@...> wrote:
          >
          > Hi KD,
          >
          > I think you were addressing me, although it has been a while since I
          went by the name Howard :-)
          >
          > If I understand you right then you have a question around preparing
          the backlog, and around the go-live process.
          >
          > Backlog preparation: I've not heard of the term Scrum Planning, but
          the concept makes sense. The product owner and the people around him
          (hopefully an architect, some dev and qa people) have to translate the
          vision into features/stories. I advise to run a sprint for it, so the
          activity is timeboxed, has stand-ups etc. And I advise not to spend
          too much time, a backlog is never right, never done, can always be
          corrected. So start building and demonstrating results as soon as
          possible. The feedback loop that you create this way will improve your
          backlog and improve the product. If your product is complex, all new
          technology, new architecture then you may need a Sprint Zero - proving
          the architecture to work with real features. A well functioning team
          of product owner / architect should be able to merge the Scrum
          Planning with the Sprint Zero concept. It is not easy though, expect
          to fail and learn, it is a lot more productive then a year of design
          and architecture work though.
          >
          > Releasing to production: for new teams a hardening sprint (the
          concept you describe) is often needed to 'go live', there is work that
          doesn't seem to fit in a Sprint. Don't forget the 'art of the
          possible' to continuously improve on what doesn't seem to fit. It
          doesn't all happen in 3 or 6 months. The largest company that I worked
          with took 14 months to crack this nut, and another 6 to become best in
          class (according to Cutter). A lot of hard work, discussions, and
          technology improvements were needed. And now they deliver shippable
          software every month.
          >
          > Hope this helps, let me know where you're specifically struggling.
          >
          > --Hubert
          >
          > karikday <karikday@...> wrote: Hi Howard,
          > From the CSM class, we were taught that there are two types of
          > planning - scrum planning and sprint planning. Scrum planning
          > involves the activities required to produce a healthy product backlog.
          > Depending on the initiative, this could be a day or a week. Sprint
          > planning is the quick planning sessions that take place as part of
          > every sprint - ending with a healthy sprint backlog.
          >
          > We have talked about this as a team and as I've said, haven't come up
          > with anything that really works well. So just to be clear, I'm not
          > talking about sprint planning - those activities are very clear,
          > defined and focused. Coordinating all of the activities to get a
          > project together and a healthy product backlog...not so much.
          >
          > During the same course, we were taught that at the end of each sprint
          > the customer can choose to promote the completed work to "production".
          > Again we've tried a few different ways of tracking the work that
          > needs to be done to promote. Again, we're just looking to hear what
          > others are doing. What we had been doing most often was stop, have a
          > special sprint specifically for promotion activities, then get back to
          > our normal development/testing sprints afterward. Our promotion
          > process may be more/less complex than other companies, so we may not
          > be able to leverage that much...but are still interested.
          >
          > --- In scrumdevelopment@yahoogroups.com, Hubert Smits
          > wrote:
          > >
          > > Hey KD,
          > >
          > > It feels like you're trying to organize the events, I would ask the
          > team the questions you are asking here. They have to invent the
          > practices that work, self-organize. It also feels that your planning
          > event is rather long, how much time do you spend in Sprint planning. I
          > see events which take 3 or 4 hours. And what is the promotion stage
          > you mention, I never came across this term.
          > >
          > > --Hubert
          > >
          > > karikday wrote: We continue to struggle with activity
          > tracking during "Scrum
          > > Planning" and "Promotion". I realize that every company has
          > > different planning, promotion procedures and timeframes, however,
          > > I'd be interested in hearing whether others are using to track the
          > > activities that take place during these timeframes.
          > >
          > > During Scrum Planning there are activities other than story writing
          > > workshops, such as vendor coordination, job shadowing, business
          > > process discovery, scrum overview/coaching for new team members,
          > > etc. During promotion, much less various tasks occur, but tasks none
          > > the less. The sprint backlog works so well for sprints that we
          > > thought we'd try to use them for these activities too - and it just
          > > didn't work out as well as we thought. Primarily because there are a
          > > bunch of discovery activities the IT team needs to have with the
          > > customer to get our arms around their business need and current
          > > process. We're not really concerned about team capacity or hours
          > > left - more about getting the activities done at the best times. Our
          > > focus is to learn as much as we can before having the official "story
          > > writing workshops". Examples could be "Model existing business
          > > process", "Talk with network team about what's required to publish a
          > > secured web service", "Find out what the customer means when they say
          > > the current system doesn't always work ;)", "Review vendor
          > > specification information", etc. We feel we absolutely have to this
          > > planning in order to effectively story point.
          > >
          > > Also, what luck have you had with stand up meetings during these
          > > timeframes? We feel it's essential for team communication to have
          > > stand ups during planning, sprints, and promotion. However, without
          > > a snappy way of activity planning, they aren't nearly as effective
          > > and focused as our sprint stand ups. They almost remind me of the
          > > stand ups we had before we starting using the sprint backlog - vague
          > > and not effective in indicating whether you're getting closer to your
          > > goal.
          > >
          > > I'd love to hear what others may be doing - or not doing. If you've
          > > found an inspiring article or whitepaper - please share.
          > >
          > > Thanks,
          > > KD
          > >
          > >
          > >
          > >
          > >
          > >
          > > To Post a message, send it to: scrumdevelopment@
          > > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@
          > > Yahoo! Groups Links
          > >
          >
          >
          >
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          > Yahoo! Groups Links
          >
        • Malcolm Anderson
          ... Hi KD The first question I have is what do you mean by We re not really concerned about team capacity or hours left - more about getting the activities
          Message 4 of 6 , Oct 4, 2007
          • 0 Attachment
            > We're not really concerned about team capacity or hours
            > left - more about getting the activities done at the best times. Our
            > focus is to learn as much as we can before having the official "story
            > writing workshops". Examples could be "Model existing business
            > process", "Talk with network team about what's required to publish a
            > secured web service", "Find out what the customer means when they say
            > the current system doesn't always work ;)", "Review vendor
            > specification information", etc. We feel we absolutely have to this
            > planning in order to effectively story point.
             
            Hi KD
             
            The first question I have is what do you mean by "We're not really concerned about team capacity or hours
            left - more about getting the activities done at the best times"?  The statement doesn't fit my concept of how software development works anywhere.  Because of that, it could be that I didn't understand your post, and that the rest of this post will not be relevant to you or your company's situation.
             
            That being said, the biggest thing that stands out for me in your post is that I see no mention of:
            1) Project ROI, or
            2) Continuous Integration. 
             
            Coming up with a projected ROI can be a short-cut to being able to determine the all important project mission.  Another way of looking at this is that it answer the question "why are we doing this?" 
             
            It seems that the team may be doing too much up front design, while at the same time not doing enough up front business analysis.
             
            For me, one of the biggest values of using agile development is that a company can cancel an unprofitable project before it has sunk too much money into it.  I often get the weirdest looks for saying this but this has really helped me when I've been communicating with the CxO ranks.  I hope we can all agree that the point of any project is to either increase profits, or cut costs.  Money goes in, and then money or saving are supposed to come out.
             
            If a project is projected to cost 2 million dollars and provide 150 million dollars worth of benefit, then if it turns out that after a sprint or six (and spending 100,000), it's actually a 20 million dollar job, the CxO can say, "It's still a good investment, full steam ahead".
             
            But if a project is projected to cost 2 million dollars and provide 15 million dollars worth of benefit, then if turns out that a sprint or six (and spending 100,000), it's actually a 20 million dollar job, the CxO can say, "This is a bad investment, cancel this project, and find a more profitable one.  Oh, and by the way, thank you for saving me 1.9 million dollars"
             
            I've got an article related to this kind of math at http://geekswithblogs.net/geekusconlivus/archive/2007/07/13/113921.aspx
             
            The other thing I mentioned is Continuous Integration.  This lets you have a fully integrated product on day one.  It may not do anything on day one, but since integration tends to be almost as expensive (some say more expensive) than the actual development, you can keep those costs down by handling it up front as opposed to being surprised by it at the end.  It also takes the entire "Promotion" phase, and makes it a non-issue.
             
            Then depending on your situation, you can either roll out your product on an on going migrational basis, replacing pieces of your existing process with new pieces that are either more profitable or cheaper to maintain, or, if your doing shrink-wrap, you can put out a 1.0 product that handles a small percentage of your customers problem set, and use the profits from the 1.0 sales, to supplement your on going 2.0 efforts.  Microsoft has made billions by being agile on this macro level.
             
            As you can see, I believe that measuring ROI and cash flow is one of the best ways to be able to demonstrate that your efforts are in the companies best interests.
             
            Again, I'm not sure that this post is 100% relevant to your question, and apologies if it doesn't provide any value to you.
             
            Malcolm
          Your message has been successfully submitted and would be delivered to recipients shortly.