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

Length of sprint planning meetings

Expand Messages
  • Jo Newcombe Cook
    Hi all We are struggling with timing on sprint planning meetings on some of our projects and I m not sure why. Prior to the planning meeting our backlog is
    Message 1 of 12 , Sep 1, 2008
    • 0 Attachment
      Hi all
       
      We are struggling with timing on sprint planning meetings on some of our projects and I'm not sure why.
       
      Prior to the planning meeting our backlog is prepared with the story, acceptance test criteria, etc. Our sprints are 4 weeks long but we have manual testing processes at the moment (I know!!) so we usually set aside the last week for regression testing and rework cycles. Our teams have 5-9 people.
       
      Our project work is customising our software for our clients, so it is effectively like maintenance/change work for existing products. We need to take existing functionality into account including any impacts on how the current system works. Once in the planning meeting we look at each story, work out what it means and break it up into tasks. We then use planning poker to come up with estimates for the tasks.
       
      The problem is this seems to be taking a long time, and planning meetings don't get through all the stories that we have time allocated for in our sprint. The latest sprint one team have just had included planning discussions over around 2.5 days!
       
      The information discussed is very valid and important for figuring out how we will make the change, team members discussing valid points about issues with certain approaches, and therefore determining what the tasks are.
       
      Am I missing something? How can we decrease the time taken for planning? Are we going too detailed into task planning? If we don't go into this discuss about the "how" aren't we likely to miss some important tasks and overcommit?
       
      I am keen to hear others thoughts on this, particularly for software well into its development.
       
      Regards,
      Jo
    • Ron Jeffries
      Hello, Jo. On Tuesday, September 2, 2008, at 12:46:09 AM, you ... I suspect you re going into way too much detail. And if you over-commit, so what? Learn from
      Message 2 of 12 , Sep 1, 2008
      • 0 Attachment
        Hello, Jo. On Tuesday, September 2, 2008, at 12:46:09 AM, you
        wrote:

        > Am I missing something? How can we decrease the time taken for planning?
        > Are we going too detailed into task planning? If we don't go into this
        > discuss about the "how" aren't we likely to miss some important tasks
        > and overcommit?

        I suspect you're going into way too much detail. And if you
        over-commit, so what? Learn from it.

        Try planning poker.

        Or, maybe try an experiment. For each story, as soon as it is read,
        everyone writes their estimate on a card and puts it face down.
        After a few minutes of discussion, write down another estimate and
        put it face down. (Mark the cards so you'll know which is first
        etc.) At the end of "enough" discussion, make a third card.

        Take the average of the first cards, of the second cards, and of the
        third cards. If the averages do not vary widely, what does that
        suggest? If they do, note how they vary. Figure out why.

        Ron Jeffries
        www.XProgramming.com
        Get over it. -- The Eagles
      • Jo Newcombe Cook
        Hi Ron I like your suggestion about the face down estimates... I might suggest that we try that. So you are suggesting that we estimate the stories as a whole?
        Message 3 of 12 , Sep 1, 2008
        • 0 Attachment
          Hi Ron
           
          I like your suggestion about the face down estimates... I might suggest that we try that.
           
          So you are suggesting that we estimate the stories as a whole? Right now we break the stories down into tasks and estimate those. If we don't break down the stories into tasks during planning, when would we do this? Prior to starting to implement the story?
           
          Regards,
          Jo
           

        • Sarath Kummamuru
          Hi Jo, Planning poker and story points work well when they are used to estimate user stories as a whole with the whole team estimating them. From what i see
          Message 4 of 12 , Sep 2, 2008
          • 0 Attachment
            Hi Jo,
                Planning poker and story points work well when they are used to estimate user stories as a whole with the whole team estimating them.

               From what i see you said you were estimating the tasks as user stories, with can get very intensive as you said.

               The normal mechanism that has worked for me is that we have teams estimate the user stories in story points before they start any of their sprints and once in a while when new stories are added during the sprints in a particular release. Not for each task.

               The sprint planning session should basically be a design discussion and design decisions meeting that allows the whole team to understand the design goals (ui, high level and may be low level design, test case design, etc).

               The tasks for the sprint should be derived from the design discussion and can be estimated in hours by any one who thinks they are competent to complete the task and if there is any major disagreement with the estimate the team can have a time boxed discussion to discuss the task estimate. (But this should be pretty quick). One thing to remember is that the tasks estimates are only estimates to drive the sprint goal and sprint burn down to indicate to the team the amount of work involved.

            These are not to be taken as commitments and that is some thing you might want to keep in mind to get your team to time box estimation discussions.

            thanks,
            Sarath.

            On Tue, Sep 2, 2008 at 11:04 AM, Jo Newcombe Cook <jo@...> wrote:

            Hi Ron
             
            I like your suggestion about the face down estimates... I might suggest that we try that.
             
            So you are suggesting that we estimate the stories as a whole? Right now we break the stories down into tasks and estimate those. If we don't break down the stories into tasks during planning, when would we do this? Prior to starting to implement the story?
             
            Regards,
            Jo
             


          • hmeftah
            Hi Jo, Yes, you re right 2.5 days for estimate it s too long, a couple of hours should be the norm. 1) Ummh! Well!!! You need to shrink/split your Sprint in 2
            Message 5 of 12 , Sep 2, 2008
            • 0 Attachment
              Hi Jo,

              Yes, you're right 2.5 days for estimate it's too long, a couple of
              hours should be the norm.

              1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
              weeks is too long. Most of the time is over-specified, you have to
              inspect and adapt your Sprint as soon possible.
              2) Identify the main story/change/maintenance/features of your
              application needs with the Project Owner.
              3) Try to use "playing poker by pair" same as "pair programming" to
              avoid any person willing to be very defensive about tasks duration.
              4) Rotating people for the second round, if there is an odd number of
              people, play as a develop member with the remaining person to get her
              feedback.

              The aim is to get a roughly realistic( not the defensive one ;-))
              estimate, start the first Sprint for having team velocity, and
              improving it ASAP by coaching, supporting individuals daily.

              Good luck
              Herve Meftah
            • Ron Jeffries
              Hello, Jo. On Tuesday, September 2, 2008, at 1:34:52 AM, you ... Well, first of all, tasks are teh suck. Breaking the job up into tasks means you have to put
              Message 6 of 12 , Sep 2, 2008
              • 0 Attachment
                Hello, Jo. On Tuesday, September 2, 2008, at 1:34:52 AM, you
                wrote:

                > So you are suggesting that we estimate the stories as a whole? Right now
                > we break the stories down into tasks and estimate those. If we don't
                > break down the stories into tasks during planning, when would we do
                > this? Prior to starting to implement the story?

                Well, first of all, tasks are teh suck. Breaking the job up into
                tasks means you have to put it back together, which is always
                difficult. I'm writing a Kate chapter about that right now.

                What I recommend is this:

                1. Product owner writes story on whiteboard, explains it.
                2. Developers /briefly/ brainstorm and list technical steps needed,
                (like tasks but not going to be done as tasks nor tracked).
                3. Repeat until enough stories are on board.
                4. Look at the list, draw the line where you can accomplish all
                above the line.
                5. Commit.
                6. Do stories as a unit, not broken into tasks.
                Burn stories, not tasks.

                Q: But for this to work, everyone would have to be able to work on
                everything.
                A: Yes, that would be ideal. And you could do pair programming --
                that would fill in needed skills and people would learn as well.

                Q: But even so, for this to work, stories would have to be very
                small.
                A: Yes.

                Hmm. Time to blog that.

                Ron Jeffries
                www.XProgramming.com
                I have tried in my way to be free. -- Leonard Cohen
              • srinivas chillara
                  Hello Jo,   In my experience with over a dozen teams(Im a coach), I have found following the book reccomendation (8hrs planning for 4 week sprint, 4 hrs
                Message 7 of 12 , Sep 2, 2008
                • 0 Attachment
                   
                  Hello Jo,
                   
                  In my experience with over a dozen teams(Im a coach), I have found following the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week sprint) works almost perfectly in the vast majority of cases. Spending significantly more time, is wasted effort, and less time results in being foggy and disorganised.
                   
                  I would say try your best to "go by the book". Then for some reason if that is not satisfactory (via discussions/retrospectives) then think of shortening/lengthening gradually.
                  Trying to follow the book is important, most people start customising this without learning the ropes of Scrum, and understanding how it should/can work very well.
                   
                  cheers
                  Srinivas 
                  From: hmeftah <hmeftah@...>
                  Subject: [scrumdevelopment] Re: Length of sprint planning meetings
                  To: scrumdevelopment@yahoogroups.com
                  Date: Tuesday, 2 September, 2008, 5:38 PM

                  Hi Jo,

                  Yes, you're right 2.5 days for estimate it's too long, a couple of
                  hours should be the norm.

                  1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
                  weeks is too long. Most of the time is over-specified, you have to
                  inspect and adapt your Sprint as soon possible.
                  2) Identify the main story/change/ maintenance/ features of your
                  application needs with the Project Owner.
                  3) Try to use "playing poker by pair" same as "pair programming" to
                  avoid any person willing to be very defensive about tasks duration.
                  4) Rotating people for the second round, if there is an odd number of
                  people, play as a develop member with the remaining person to get her
                  feedback.

                  The aim is to get a roughly realistic( not the defensive one ;-))
                  estimate, start the first Sprint for having team velocity, and
                  improving it ASAP by coaching, supporting individuals daily.

                  Good luck
                  Herve Meftah



                  Add more friends to your messenger and enjoy! Invite them now.
                • Cenk Çivici
                  - Make your sprints short so you have less stories to plan and estimate. Planning meeting for a 4 week iteration will probably take 4 times as long compared to
                  Message 8 of 12 , Sep 3, 2008
                  • 0 Attachment
                    - Make your sprints short so you have less stories to plan and estimate.
                    Planning meeting for a 4 week iteration will probably take 4 times as
                    long compared to a 1 week iteration

                    - Prepare for the meeting. (dont make decisions before but review the
                    cards, analyze dev tasks etc)



                    On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@...> wrote:
                    >
                    > Hello Jo,
                    >
                    > In my experience with over a dozen teams(Im a coach), I have found following
                    > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week
                    > sprint) works almost perfectly in the vast majority of cases. Spending
                    > significantly more time, is wasted effort, and less time results in being
                    > foggy and disorganised.
                    >
                    > I would say try your best to "go by the book". Then for some reason if that
                    > is not satisfactory (via discussions/retrospectives) then think of
                    > shortening/lengthening gradually.
                    > Trying to follow the book is important, most people start customising this
                    > without learning the ropes of Scrum, and understanding how it should/can
                    > work very well.
                    >
                    > cheers
                    > Srinivas
                    >
                    > From: hmeftah <hmeftah@...>
                    > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
                    > To: scrumdevelopment@yahoogroups.com
                    > Date: Tuesday, 2 September, 2008, 5:38 PM
                    >
                    > Hi Jo,
                    >
                    > Yes, you're right 2.5 days for estimate it's too long, a couple of
                    > hours should be the norm.
                    >
                    > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
                    > weeks is too long. Most of the time is over-specified, you have to
                    > inspect and adapt your Sprint as soon possible.
                    > 2) Identify the main story/change/ maintenance/ features of your
                    > application needs with the Project Owner.
                    > 3) Try to use "playing poker by pair" same as "pair programming" to
                    > avoid any person willing to be very defensive about tasks duration.
                    > 4) Rotating people for the second round, if there is an odd number of
                    > people, play as a develop member with the remaining person to get her
                    > feedback.
                    >
                    > The aim is to get a roughly realistic( not the defensive one ;-))
                    > estimate, start the first Sprint for having team velocity, and
                    > improving it ASAP by coaching, supporting individuals daily.
                    >
                    > Good luck
                    > Herve Meftah
                    >
                    >
                    > ________________________________
                    > Add more friends to your messenger and enjoy! Invite them now.
                    >
                  • Cenk Çivici
                    - Spending significantly more time, is wasted effort, and less time results in being foggy and disorganised 4 hours is too long. Our meetings are usually 1-3
                    Message 9 of 12 , Sep 3, 2008
                    • 0 Attachment
                      - Spending significantly more time, is wasted effort, and less time
                      results in being foggy and disorganised

                      4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week
                      iteration.
                      Can you explain why you think spending less than 4 hours results in
                      being foggy or disorganised?



                      On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@...> wrote:
                      >
                      > Hello Jo,
                      >
                      > In my experience with over a dozen teams(Im a coach), I have found following
                      > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week
                      > sprint) works almost perfectly in the vast majority of cases. Spending
                      > significantly more time, is wasted effort, and less time results in being
                      > foggy and disorganised.
                      >
                      > I would say try your best to "go by the book". Then for some reason if that
                      > is not satisfactory (via discussions/retrospectives) then think of
                      > shortening/lengthening gradually.
                      > Trying to follow the book is important, most people start customising this
                      > without learning the ropes of Scrum, and understanding how it should/can
                      > work very well.
                      >
                      > cheers
                      > Srinivas
                      >
                      > From: hmeftah <hmeftah@...>
                      > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
                      > To: scrumdevelopment@yahoogroups.com
                      > Date: Tuesday, 2 September, 2008, 5:38 PM
                      >
                      > Hi Jo,
                      >
                      > Yes, you're right 2.5 days for estimate it's too long, a couple of
                      > hours should be the norm.
                      >
                      > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
                      > weeks is too long. Most of the time is over-specified, you have to
                      > inspect and adapt your Sprint as soon possible.
                      > 2) Identify the main story/change/ maintenance/ features of your
                      > application needs with the Project Owner.
                      > 3) Try to use "playing poker by pair" same as "pair programming" to
                      > avoid any person willing to be very defensive about tasks duration.
                      > 4) Rotating people for the second round, if there is an odd number of
                      > people, play as a develop member with the remaining person to get her
                      > feedback.
                      >
                      > The aim is to get a roughly realistic( not the defensive one ;-))
                      > estimate, start the first Sprint for having team velocity, and
                      > improving it ASAP by coaching, supporting individuals daily.
                      >
                      > Good luck
                      > Herve Meftah
                      >
                      >
                      > ________________________________
                      > Add more friends to your messenger and enjoy! Invite them now.
                      >
                    • chuckspublicprofile
                      I don t know that a 1 week iteration is the answer -- that s a pretty extreme change, I would move more conservatively to a 2 week iteration and see how that
                      Message 10 of 12 , Sep 3, 2008
                      • 0 Attachment
                        I don't know that a 1 week iteration is the answer -- that's a pretty
                        extreme change, I would move more conservatively to a 2 week iteration
                        and see how that works first.

                        We do the SPM in two phases:

                        Phase 1 -- Size stories and establish point budget
                        1. PO presents backlog one item at a time.
                        2. Devs get small amount of time to ask questions, Discussion round 1.
                        3. Devs size via planning poker round 1
                        4. Outlier estimates get their short say. Discussion round 2.
                        5. Devs size via planning poker round 2
                        6. Either have ScrumMaster make exec decision (pref not) or ask if
                        the outliers can live with a more average estimate.
                        7. Once you've sized enough stories to fill the sprint budget and
                        possibly some stretch, end this part of the meeting.

                        If Steps 2-6 seem to drag on, you need a way of quickening the
                        process. I call this a "collision" or "decision" strategy. Examples
                        from roughly slowest to roughly fastest.
                        1. Team makes unanimous decision.
                        2. Certain team members indicate that they can "live with" a
                        different estimate... (See "Fist of Five" for similar strategy)
                        3. Timebox of each discussion round.
                        4. Toss out outliers and take average.
                        5. Use Mean, Median, or Mode of all estimates.
                        6. ScrumMaster makes exec decision
                        7. Team Lead/Sr. Architect/dev makes exec decision

                        One could argue that there are more than the above strategies (I
                        welcome additions), and I think one could also argue that some of the
                        strategies above are better/worse for the team long term. Ideally you
                        want to move your team to #1 or2, but if time gets in the way, I
                        recommend using 3-7 until you can get to #1 or 2.

                        Phase one for a 2 week sprint takes us about 1 hour.

                        Phase 2
                        Devs task out each story one at a time for all stories in this sprint
                        and in the stretch work. If this process begins to take too long, we
                        try to finish at least half the work in the SPM, and then schedule a
                        VERY quick follow up meeting to task the rest.

                        Phase 2 for a 2 week sprint usually takes us 1-3 hours (depending on
                        if we use pre-tasked stretch work leftover from a previous iteration)

                        We have a working agreement that we can still change point estimates
                        during the SPM, but we almost NEVER do it at the follow up meeting.
                        This gives folks an incentive to get through the SPM on time.

                        Charles Bradley
                        CSM, SCJP


                        --- In scrumdevelopment@yahoogroups.com, "Cenk Çivici"
                        <cenk.civici@...> wrote:
                        >
                        > - Make your sprints short so you have less stories to plan and estimate.
                        > Planning meeting for a 4 week iteration will probably take 4 times as
                        > long compared to a 1 week iteration
                        >
                        > - Prepare for the meeting. (dont make decisions before but review the
                        > cards, analyze dev tasks etc)
                        >
                        >
                        >
                        > On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@...> wrote:
                        > >
                        > > Hello Jo,
                        > >
                        > > In my experience with over a dozen teams(Im a coach), I have found
                        following
                        > > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs
                        for a 2 week
                        > > sprint) works almost perfectly in the vast majority of cases. Spending
                        > > significantly more time, is wasted effort, and less time results
                        in being
                        > > foggy and disorganised.
                        > >
                        > > I would say try your best to "go by the book". Then for some
                        reason if that
                        > > is not satisfactory (via discussions/retrospectives) then think of
                        > > shortening/lengthening gradually.
                        > > Trying to follow the book is important, most people start
                        customising this
                        > > without learning the ropes of Scrum, and understanding how it
                        should/can
                        > > work very well.
                        > >
                        > > cheers
                        > > Srinivas
                        > >
                        > > From: hmeftah <hmeftah@...>
                        > > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
                        > > To: scrumdevelopment@yahoogroups.com
                        > > Date: Tuesday, 2 September, 2008, 5:38 PM
                        > >
                        > > Hi Jo,
                        > >
                        > > Yes, you're right 2.5 days for estimate it's too long, a couple of
                        > > hours should be the norm.
                        > >
                        > > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
                        > > weeks is too long. Most of the time is over-specified, you have to
                        > > inspect and adapt your Sprint as soon possible.
                        > > 2) Identify the main story/change/ maintenance/ features of your
                        > > application needs with the Project Owner.
                        > > 3) Try to use "playing poker by pair" same as "pair programming" to
                        > > avoid any person willing to be very defensive about tasks duration.
                        > > 4) Rotating people for the second round, if there is an odd number of
                        > > people, play as a develop member with the remaining person to get her
                        > > feedback.
                        > >
                        > > The aim is to get a roughly realistic( not the defensive one ;-))
                        > > estimate, start the first Sprint for having team velocity, and
                        > > improving it ASAP by coaching, supporting individuals daily.
                        > >
                        > > Good luck
                        > > Herve Meftah
                        > >
                        > >
                        > > ________________________________
                        > > Add more friends to your messenger and enjoy! Invite them now.
                        > >
                        >
                      • srinivas chillara
                        4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week iteration. Can you explain why you think spending less than 4 hours results in being
                        Message 11 of 12 , Sep 3, 2008
                        • 0 Attachment
                          "4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week
                          iteration.
                          Can you explain why you think spending less than 4 hours results in
                          being foggy or disorganised?"


                          Well, it is simply an emperical observation (over a couple of years and many teams), and felt the book reccomendation worked really well. 4 hrs for a 2 weeks were usually required, especially if close to zero pre-planning activity.


                          So I can't really explain why 4 hrs is the right duration for a SPM.
                          What I can tell is: what usually happens when teams try to do the SPM in 3 hrs or less. They take about 2.5 hrs to understand the product backlog, discuss and agree upon the number of items to commit. Then they hurridly do the task breakdown for the commitment. THey usually don't do a cross-check if they can actually meet the commitment, and leave no time for any meaningful negotiation with the PO. Actually in most cases, in a 2 to 3 sprints they realise this (during retros) and go for hte 4 hrs.

                          cheers
                          Srinivas





                          Did you know? You can CHAT without downloading messenger. Go to http://in.webmessenger.yahoo.com/
                        • srinivas chillara
                          This is not to say that 4 hrs should not be revised upwards or down, but simply to mean that the teams should really try hard to make do 4 hrs, and with
                          Message 12 of 12 , Sep 3, 2008
                          • 0 Attachment
                            This is not to say that 4 hrs should not be revised upwards or down, but simply to mean that the teams should really try hard to make do 4 hrs, and with experience change the duration of the SPM.
                            Srinivas

                            --- On Wed, 3/9/08, Cenk Çivici <cenk.civici@...> wrote:
                            From: Cenk Çivici <cenk.civici@...>
                            Subject: Re: [scrumdevelopment] Re: Length of sprint planning meetings
                            To: scrumdevelopment@yahoogroups.com
                            Date: Wednesday, 3 September, 2008, 8:54 PM

                            - Spending significantly more time, is wasted effort, and less time
                            results in being foggy and disorganised

                            4 hours is too long. Our meetings are usually 1-3 hours, We use 2 week
                            iteration.
                            Can you explain why you think spending less than 4 hours results in
                            being foggy or disorganised?

                            On Tue, Sep 2, 2008 at 6:02 PM, srinivas chillara <ceezone@yahoo. co.in> wrote:
                            >
                            > Hello Jo,
                            >
                            > In my experience with over a dozen teams(Im a coach), I have found following
                            > the book reccomendation (8hrs planning for 4 week sprint, 4 hrs for a 2 week
                            > sprint) works almost perfectly in the vast majority of cases. Spending
                            > significantly more time, is wasted effort, and less time results in being
                            > foggy and disorganised.
                            >
                            > I would say try your best to "go by the book". Then for some reason if that
                            > is not satisfactory (via discussions/ retrospectives) then think of
                            > shortening/lengthen ing gradually.
                            > Trying to follow the book is important, most people start customising this
                            > without learning the ropes of Scrum, and understanding how it should/can
                            > work very well.
                            >
                            > cheers
                            > Srinivas
                            >
                            > From: hmeftah <hmeftah@yahoo. com>
                            > Subject: [scrumdevelopment] Re: Length of sprint planning meetings
                            > To: scrumdevelopment@ yahoogroups. com
                            > Date: Tuesday, 2 September, 2008, 5:38 PM
                            >
                            > Hi Jo,
                            >
                            > Yes, you're right 2.5 days for estimate it's too long, a couple of
                            > hours should be the norm.
                            >
                            > 1) Ummh! Well!!! You need to shrink/split your Sprint in 2 weeks, 4
                            > weeks is too long. Most of the time is over-specified, you have to
                            > inspect and adapt your Sprint as soon possible.
                            > 2) Identify the main story/change/ maintenance/ features of your
                            > application needs with the Project Owner.
                            > 3) Try to use "playing poker by pair" same as "pair programming" to
                            > avoid any person willing to be very defensive about tasks duration.
                            > 4) Rotating people for the second round, if there is an odd number of
                            > people, play as a develop member with the remaining person to get her
                            > feedback.
                            >
                            > The aim is to get a roughly realistic( not the defensive one ;-))
                            > estimate, start the first Sprint for having team velocity, and
                            > improving it ASAP by coaching, supporting individuals daily.
                            >
                            > Good luck
                            > Herve Meftah
                            >
                            >
                            > ____________ _________ _________ __
                            > Add more friends to your messenger and enjoy! Invite them now.
                            >


                            Unlimited freedom, unlimited storage. Get it now
                          Your message has been successfully submitted and would be delivered to recipients shortly.