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

Scrum Planning and Promotion Activities

Expand Messages
  • karikday
    We continue to struggle with activity tracking during Scrum Planning and Promotion . I realize that every company has different planning, promotion
    Message 1 of 6 , Sep 24, 2007
      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
    • Hubert Smits
      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
      Message 2 of 6 , Sep 25, 2007
        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

        <*> 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/


      • 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 3 of 6 , Oct 3, 2007
          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 4 of 6 , Oct 3, 2007
            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 5 of 6 , Oct 4, 2007
              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 6 of 6 , Oct 4, 2007
                > 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.