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

Complexity X Time

Expand Messages
  • Rafael Nascimento
    Hi people! It s been very hard for me to separate complexity and time when we re planning a sprint. I see them too close. I mean, if a story is too complex, it
    Message 1 of 17 , Jun 30, 2010
      Hi people!

      It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

      Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

      Best regards!
    • Mark Levison
      On Wed, Jun 30, 2010 at 9:43 PM, Rafael Nascimento
      Message 2 of 17 , Jun 30, 2010
        On Wed, Jun 30, 2010 at 9:43 PM, Rafael Nascimento <rafaelnascimento.rj@...> wrote:
         

        Hi people!

        It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

        In fact if you read Mike Cohn's recent blog post on the subject and a thread either on this list or the Scrum Alliance list - you don't. Story Points are intended to measure effort. I.E. the time the team members believe it will take.


        Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

        Estimates of absolute time decay have numerous problems:
        - How long will it take you to leave the office, pickup the kids, go to the grocery store and pickup your spouses cleaning. Please provide a precise estimate of when you will be home. Hmmmm you arrived 30 minutes later than the estimate, why? were you lazy? ...
        - As the team improves over time estimates in ideal days will decay - i.e. the team gets faster (or even automates) certain tasks, now the original estimates for the related stories no longer hold.

        There are heaps more reasons, but I'm tired and have to facilitate an Innovation Games session tomorrow.

        Cheers
        Mark


        Best regards!


      • Adam Sroka
        Story points are meant to be a measurement of effort and not complexity. Mike Cohn actually blogged about this just over a week ago
        Message 3 of 17 , Jun 30, 2010
          Story points are meant to be a measurement of effort and not
          complexity. Mike Cohn actually blogged about this just over a week ago
          (http://blog.mountaingoatsoftware.com/its-effort-not-complexity)

          The notion of estimating complexity is one of the things that was
          experimented with in the early days of XP (Gummy Bears... I couldn't
          find a good reference), but it is difficult to use effectively.
          Complexity doesn't correlate strongly to time, as Mike illustrates
          with his analogy (licking 1,000 stamps vs. performing brain surgery.)

          If you are measuring velocity, and you want that measurement to be
          stable enough to be useful, then you need something that is roughly
          comparable to time. The best thing (besides ignoring velocity, which
          is what I actually recommend) is stories of roughly comparable size so
          that velocity is the number of stories done per iteration averaged out
          over a period of time. The next best thing is story points that
          roughly correlate to same vague idea of relative effort, because
          effort is comparable to time.

          On Wed, Jun 30, 2010 at 6:43 PM, Rafael Nascimento
          <rafaelnascimento.rj@...> wrote:
          >
          >
          >
          > Hi people!
          >
          > It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.
          >
          > Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?
          >
          > Best regards!
          >
          >
        • Adam Sroka
          P.S. the reason Schwaber didn t write anything about story points is that they weren t a part of Scrum (neither were stories.) These ideas come from XP. Mike
          Message 4 of 17 , Jun 30, 2010
            P.S. the reason Schwaber didn't write anything about story points is that they weren't a part of Scrum (neither were stories.) These ideas come from XP. Mike Cohn popularized them with his book and many Scrum teams subsequently adopted them. Unfortunately, many Scrum teams seem to have conflated ideas from the XP planning game with Scrum's description of Sprint/Release planning in a way that dilutes the effectiveness of either approach (e.g. creating "technical stories" or assuming that all work that has to be done must be sized in points.)

            On Wed, Jun 30, 2010 at 6:43 PM, Rafael Nascimento <rafaelnascimento.rj@...> wrote:
             

            Hi people!

            It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

            Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

            Best regards!


          • Rafael Nascimento
            Hi guys! So I was completely wrong in my thinking, and I m really sorry for that! Actually, our sprint planning meeting was showing me that story points as
            Message 5 of 17 , Jun 30, 2010
              Hi guys!

              So I was completely wrong in my thinking, and I'm really sorry for that!

              Actually, our sprint planning meeting was showing me that story points as complexity were making the team struggle a lot, and our planning was getting too long because of this.

              A just read Cohn's post, and he was enfatic: story points are about effort, and effort is about time.

              Thanks!

              2010/6/30 Adam Sroka <adam.sroka@...>
               

              P.S. the reason Schwaber didn't write anything about story points is that they weren't a part of Scrum (neither were stories.) These ideas come from XP. Mike Cohn popularized them with his book and many Scrum teams subsequently adopted them. Unfortunately, many Scrum teams seem to have conflated ideas from the XP planning game with Scrum's description of Sprint/Release planning in a way that dilutes the effectiveness of either approach (e.g. creating "technical stories" or assuming that all work that has to be done must be sized in points.)

              On Wed, Jun 30, 2010 at 6:43 PM, Rafael Nascimento <rafaelnascimento.rj@...> wrote:
               

              Hi people!

              It's been very hard for me to separate complexity and time when we're planning a sprint. I see them too close. I mean, if a story is too complex, it means the team spend more time to complete this story.

              Within the first Schwaber book about Scrum, he does not mention Story Points or Planning Poker or Fibonacci. Just time (hours and days). Why do we need to estimate the complexity, and not just the time?

              Best regards!



            • Adam Sroka
              On Wed, Jun 30, 2010 at 7:44 PM, Rafael Nascimento ... Don t be sorry. Like I said, early XP adopters tried this idea too, and a lot of them were really smart
              Message 6 of 17 , Jun 30, 2010
                On Wed, Jun 30, 2010 at 7:44 PM, Rafael Nascimento
                <rafaelnascimento.rj@...> wrote:
                >
                >
                >
                > Hi guys!
                >
                > So I was completely wrong in my thinking, and I'm really sorry for that!
                >

                Don't be sorry. Like I said, early XP adopters tried this idea too,
                and a lot of them were really smart guys. Unfortunately, it just
                doesn't work that well, as you have observed.

                > Actually, our sprint planning meeting was showing me that story points as complexity were making the team struggle a lot, and our planning was getting too long because of this.
                >

                Yep. That's what I have seen too. Incidentally, the same is true of
                estimating effort, or ideal time. Teams seem to spend more time on
                estimation than any other single activity which does not contribute to
                actual working software. This might lead you to conclude that they
                would get more done if they just didn't estimate. In fact, this
                appears to be true almost universally (Based on my own experience with
                teams and conversations I've had with peers and mentors.) This
                realization has led some teams not to estimate, or to do so on an as
                needed basis rather than as a matter of course (e.g. give a rough
                estimate for a large customer request, but don't estimate at the
                beginning of every iteration.)

                > A just read Cohn's post, and he was enfatic: story points are about effort, and effort is about time.
                >

                You actually read it? ;-)
              • Mark Levison
                On Wed, Jun 30, 2010 at 10:56 PM, Adam Sroka wrote: Yep. That s what I have seen too. Incidentally, the same is true of ... I ve not met
                Message 7 of 17 , Jun 30, 2010
                  On Wed, Jun 30, 2010 at 10:56 PM, Adam Sroka <adam.sroka@...> wrote:

                  Yep. That's what I have seen too. Incidentally, the same is true of
                  estimating effort, or ideal time. Teams seem to spend more time on
                  estimation than any other single activity which does not contribute to
                  actual working software. This might lead you to conclude that they
                  would get more done if they just didn't estimate. In fact, this
                  appears to be true almost universally (Based on my own experience with
                  teams and conversations I've had with peers and mentors.) This
                  realization has led some teams not to estimate, or to do so on an as
                  needed basis rather than as a matter of course (e.g. give a rough
                  estimate for a large customer request, but don't estimate at the
                  beginning of every iteration.)

                  I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.

                  BTW Please don't apologize. It is always good to ask questions.

                  Time for sleep
                  Mark
                  Blog | Twitter | Office: (613) 862-2538
                   
                • Ron Jeffries
                  Hello, Rafael. On Wednesday, June 30, 2010, at 9:43:07 PM, you ... You don t. In fact, you don t really even need to estimate at all. But if you do, what
                  Message 8 of 17 , Jun 30, 2010
                    Hello, Rafael. On Wednesday, June 30, 2010, at 9:43:07 PM, you
                    wrote:

                    > Within the first Schwaber book about Scrum, he does not mention Story Points
                    > or Planning Poker or Fibonacci. Just time (hours and days). Why do we need
                    > to estimate the complexity, and not just the time?

                    You don't. In fact, you don't really even need to estimate at all.
                    But if you do, what you're trying to derive is time.

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    Do as you will, try to do it well. That's what I do.
                  • Heitor Roriz Filho
                    Ron, don t need to estimate complexity or don t need to estimate *anything* at all?
                    Message 9 of 17 , Jun 30, 2010
                      Ron,

                      don't need to estimate complexity or don't need to estimate *anything* at all?

                      On Thu, Jul 1, 2010 at 12:09 AM, Ron Jeffries <ronjeffries@...> wrote:
                       

                      Hello, Rafael. On Wednesday, June 30, 2010, at 9:43:07 PM, you
                      wrote:



                      > Within the first Schwaber book about Scrum, he does not mention Story Points
                      > or Planning Poker or Fibonacci. Just time (hours and days). Why do we need
                      > to estimate the complexity, and not just the time?

                      You don't. In fact, you don't really even need to estimate at all.
                      But if you do, what you're trying to derive is time.

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      Do as you will, try to do it well. That's what I do.


                    • Adam Sroka
                      ... True, but I can imagine a highly functioning organization able to have the following conversation: Boss: We have this really big thing we d like you to
                      Message 10 of 17 , Jun 30, 2010
                        On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
                        >
                        >
                        > I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.


                        True, but I can imagine a highly functioning organization able to have
                        the following conversation:

                        Boss: "We have this really big thing we'd like you to do. What do you
                        think it'll take?"

                        Team: "We've done some other big things that aren't entirely different
                        from that thing, and they took an average of about six months. So,
                        we're thinking it'll take between four and eight months to get it all
                        into production."

                        Boss: "Great! I know that it costs about $50K to keep you guys running
                        for a month. That means that this is going to cost me about $200-400K.
                        Based on what we know of the market that should be well worth it. When
                        will you have something to show us?"

                        Team: "In about a week, but before we start let's sit down and write
                        some user stories so that we can prioritize them and get a better feel
                        for what the first pieces of functionality will be."
                      • Mark Levison
                        ... Hmmmm, I ve never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there. Cheers
                        Message 11 of 17 , Jun 30, 2010
                          On Wed, Jun 30, 2010 at 11:19 PM, Adam Sroka <adam.sroka@...> wrote:

                          True, but I can imagine a highly functioning organization able to have
                          the following conversation:

                          Boss: "We have this really big thing we'd like you to do. What do you
                          think it'll take?"

                          Team: "We've done some other big things that aren't entirely different
                          from that thing, and they took an average of about six months. So,
                          we're thinking it'll take between four and eight months to get it all
                          into production."

                          Boss: "Great! I know that it costs about $50K to keep you guys running
                          for a month. That means that this is going to cost me about $200-400K.
                          Based on what we know of the market that should be well worth it. When
                          will you have something to show us?"

                          Team: "In about a week, but before we start let's sit down and write
                          some user stories so that we can prioritize them and get a better feel
                          for what the first pieces of functionality will be."

                          Hmmmm, I've never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there.

                          Cheers
                          Mark
                          Blog | Twitter | Office: (613) 862-2538
                        • Adam Sroka
                          ... I ve not quite gotten there yet either, but I ve seen glimpses. Besides, it s good to have something to strive for ;-)
                          Message 12 of 17 , Jun 30, 2010
                            On Wed, Jun 30, 2010 at 8:22 PM, Mark Levison <mark@...> wrote:
                            >
                            >
                            >
                            > On Wed, Jun 30, 2010 at 11:19 PM, Adam Sroka <adam.sroka@...> wrote:
                            >>
                            >> True, but I can imagine a highly functioning organization able to have
                            >> the following conversation:
                            >>
                            >> Boss: "We have this really big thing we'd like you to do. What do you
                            >> think it'll take?"
                            >>
                            >> Team: "We've done some other big things that aren't entirely different
                            >> from that thing, and they took an average of about six months. So,
                            >> we're thinking it'll take between four and eight months to get it all
                            >> into production."
                            >>
                            >> Boss: "Great! I know that it costs about $50K to keep you guys running
                            >> for a month. That means that this is going to cost me about $200-400K.
                            >> Based on what we know of the market that should be well worth it. When
                            >> will you have something to show us?"
                            >>
                            >> Team: "In about a week, but before we start let's sit down and write
                            >> some user stories so that we can prioritize them and get a better feel
                            >> for what the first pieces of functionality will be."
                            >
                            > Hmmmm, I've never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there.

                            I've not quite gotten there yet either, but I've seen glimpses.
                            Besides, it's good to have something to strive for ;-)
                          • Heitor Roriz Filho
                            LOL!
                            Message 13 of 17 , Jun 30, 2010
                              LOL!

                              On Thu, Jul 1, 2010 at 12:22 AM, Mark Levison <mark@...> wrote:
                               



                              On Wed, Jun 30, 2010 at 11:19 PM, Adam Sroka <adam.sroka@...> wrote:

                              True, but I can imagine a highly functioning organization able to have
                              the following conversation:

                              Boss: "We have this really big thing we'd like you to do. What do you
                              think it'll take?"

                              Team: "We've done some other big things that aren't entirely different
                              from that thing, and they took an average of about six months. So,
                              we're thinking it'll take between four and eight months to get it all
                              into production."

                              Boss: "Great! I know that it costs about $50K to keep you guys running
                              for a month. That means that this is going to cost me about $200-400K.
                              Based on what we know of the market that should be well worth it. When
                              will you have something to show us?"

                              Team: "In about a week, but before we start let's sit down and write
                              some user stories so that we can prioritize them and get a better feel
                              for what the first pieces of functionality will be."

                              Hmmmm, I've never seen an organization like that. When you find one I want to visit as anthropologist, as I doubt I would have much to coach there.

                              Cheers


                            • Adam Sroka
                              ... Another important point -- you have to be able to think mathematically to get this, but hopefully everyone can follow: Mike Cohn says that we should
                              Message 14 of 17 , Jun 30, 2010
                                On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
                                >
                                > I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.


                                Another important point -- you have to be able to think mathematically
                                to get this, but hopefully everyone can follow:

                                Mike Cohn says that we should estimate relative sizes within an order
                                of magnitude, because more than that is hard for our brains to keep
                                track of. He also says that we should avoid adjacent numbers and use
                                either a Fibonacci sequence or powers of two.

                                That means that our numbers are distributed across a single order of
                                magnitude about logarithmically. Statistically, this variation becomes
                                insignificant after only a few iterations.

                                So, if numbers are evenly distributed among stories the average is
                                about 4 (for the set [1, 2, 3, 5, 8] the mean is 3.8 and for the set
                                [1, 2, 4, 8] the mean is 3.75) If you divide story points by that
                                average it should approximately equal the number of stories you did
                                within some small margin of error.

                                That, of course, assumes that your team evenly distributes it's
                                estimates. Most do not. For most you could look through about three to
                                five iterations, pick the number that occurs most often, and divide by
                                that. You should still get pretty close (Try it!)

                                So, if you estimate the way Mike Cohn recommends you should be just
                                about as accurate as if you just counted the number of stories.
                                Estimates are not statistically significant if done as recommended
                                (And, I submit that an attempt to make them significant would also
                                make them less accurate for the reasons that Mike explains -- adjacent
                                numbers are hard to differentiate and wide ranges of choices are hard
                                to apply consistently.)
                              • Adam Sroka
                                P.P.S. I do not mean to imply anything about Mike Cohn s intelligence here. I did it his way for years before I figured this out. I have learned a lot from
                                Message 15 of 17 , Jun 30, 2010
                                  P.P.S. I do not mean to imply anything about Mike Cohn's intelligence
                                  here. I did it his way for years before I figured this out. I have
                                  learned a lot from him.

                                  On Wed, Jun 30, 2010 at 9:02 PM, Adam Sroka <adam.sroka@...> wrote:
                                  > On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
                                  >>
                                  >> I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.
                                  >
                                  >
                                  > Another important point -- you have to be able to think mathematically
                                  > to get this, but hopefully everyone can follow:
                                  >
                                  > Mike Cohn says that we should estimate relative sizes within an order
                                  > of magnitude, because more than that is hard for our brains to keep
                                  > track of. He also says that we should avoid adjacent numbers and use
                                  > either a Fibonacci sequence or powers of two.
                                  >
                                  > That means that our numbers are distributed across a single order of
                                  > magnitude about logarithmically. Statistically, this variation becomes
                                  > insignificant after only a few iterations.
                                  >
                                  > So, if numbers are evenly distributed among stories the average is
                                  > about 4 (for the set [1, 2, 3, 5, 8] the mean is 3.8 and for the set
                                  > [1, 2, 4, 8] the mean is 3.75) If you divide story points by that
                                  > average it should approximately equal the number of stories you did
                                  > within some small margin of error.
                                  >
                                  > That, of course, assumes that your team evenly distributes it's
                                  > estimates. Most do not. For most you could look through about three to
                                  > five iterations, pick the number that occurs most often, and divide by
                                  > that. You should still get pretty close (Try it!)
                                  >
                                  > So, if you estimate the way Mike Cohn recommends you should be just
                                  > about as accurate as if you just counted the number of stories.
                                  > Estimates are not statistically significant if done as recommended
                                  > (And, I submit that an attempt to make them significant would also
                                  > make them less accurate for the reasons that Mike explains -- adjacent
                                  > numbers are hard to differentiate and wide ranges of choices are hard
                                  > to apply consistently.)
                                  >
                                • Ron Jeffries
                                  Hello, Heitor. On Wednesday, June 30, 2010, at 11:18:36 PM, you ... If you want to estimate, estimate time. If you don t want to estimate, there is no real
                                  Message 16 of 17 , Jun 30, 2010
                                    Hello, Heitor. On Wednesday, June 30, 2010, at 11:18:36 PM, you
                                    wrote:

                                    > don't need to estimate complexity or don't need to estimate *anything* at
                                    > all?

                                    If you want to estimate, estimate time. If you don't want to
                                    estimate, there is no real need to do so.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    www.xprogramming.com/blog
                                    It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
                                  • Jay Conne
                                    Adam & Mark, I find the estimating of stories and tasks done with a light touch is no a waste, but rather a communication of expectations. For Stories, using
                                    Message 17 of 17 , Jul 1, 2010
                                      Adam & Mark,

                                      I find the estimating of stories and tasks done with a light touch is no a waste, but rather a communication of expectations.

                                      For Stories, using Mike Cohn's guidance on numerical estimating, I find setting the expectation that it should no more accurate than the metaphor of t-shirt sizes: S, M, L, XL (XXL?) that frees people to have a quick consensus on what's being committed to when a team takes on a story.

                                      For tasks, also using a light touch, it's a quick and easy step to communicate evolving expectations that can be changed on the fly as learning takes place. This informs transparent communication to all stakeholders of the sate of an iteration.

                                      I find that Adam's scenario is exactly what I encourage for my clients. It starts with acknowledging what's known and not known. This also resembles my advice to CIOs in talking to their CEOs and budgeting committees: Based on this investment rate, like funding an R&D organization, I can do this much (X) for sure. If we're really lucky in discovering and developing new functionality, I can envision this dream level (Y) being achieved. And we are most likely to reach some intermediate level of functionality (Z). If X is sufficient for funding our loaded flow rate, let's get started.

                                      Anyone with experience knows that any other statement of certainty is self-deception or worse. However, many people are so steeped in a false claims of predictability as a standard of professionalism that it's difficult to change those organizations.

                                      In my Agile consulting, my prime objective is to create a safe environment for all to say, "I don't know." Then we can focus on delivery good stuff fast. As a matter of integrity, I hope all of us Agile, Scrum, XP, Kanban, Lean, etc. consultants do the same.

                                      Jay
                                      www.jconne.com

                                      --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                      >
                                      > On Wed, Jun 30, 2010 at 8:02 PM, Mark Levison <mark@...> wrote:
                                      > >
                                      > >
                                      > > I've not met Adam so can claim to be neither a mentor or peer. However my experience chimes with his. Estimation is a waste. Estimation of tasks in hours is utter waste, people spend hours debating minutia, when they would better off just starting. Even estimation of stories in points is a waste, however to make your projects progress predictable and transparent this requires that stories be roughly the same size +/- one Delta. For most teams (mature or not) this turns out to be difficult, so they stick to story points.
                                      >
                                      >
                                      > True, but I can imagine a highly functioning organization able to have
                                      > the following conversation:
                                      >
                                      > Boss: "We have this really big thing we'd like you to do. What do you
                                      > think it'll take?"
                                      >
                                      > Team: "We've done some other big things that aren't entirely different
                                      > from that thing, and they took an average of about six months. So,
                                      > we're thinking it'll take between four and eight months to get it all
                                      > into production."
                                      >
                                      > Boss: "Great! I know that it costs about $50K to keep you guys running
                                      > for a month. That means that this is going to cost me about $200-400K.
                                      > Based on what we know of the market that should be well worth it. When
                                      > will you have something to show us?"
                                      >
                                      > Team: "In about a week, but before we start let's sit down and write
                                      > some user stories so that we can prioritize them and get a better feel
                                      > for what the first pieces of functionality will be."
                                      >
                                    Your message has been successfully submitted and would be delivered to recipients shortly.