Question: Explaining Impediments to the Sprint Goal that happen

I received this email with a question:

Hi Joe,
I wanted to follow up and let you know how much I enjoyed the Agile class and how much I’ve enjoyed implementing it at my office.

The team has really seen the improvement with their own eyes, and they are getting more and more brought in each day. We are already on our second release plan since the class. Our start Velocity with seven developers the first Sprint was only 18, but by the last Sprint we were getting close to 50 points. This current release plant we are averaging right under 60 points per Sprint. It’s been amazing the turnaround in such a short time.

Now to my question, how do you relate loss of staff time to your stakeholders, due to sickness? For example, we had a user story planned for a Sprint, but the staff person who needed to be involved in it’s design has been sick. I’ve let the stakeholders know that it may not be finished in the Sprint due to illness, but beyond that, I’m not sure what else I can do.

Just reaching out for advice, thanks Joe!  Regards, Tony […]

ANSWER:

In the title, I use the words ‘…that happen…’ By this I mean, an impediment that was unexpected that arises during the Sprint. If it were a different situation, I might give a different answer.

First: We want the Velocity to be meaningful. Remind them there is no value in fudging the numbers. It is good and useful to be honest. If you all do things ‘according to the book’ it is actually hard to fudge the numbers, but not everyone explains enough so that it can be seen that they are (or are not) playing ‘by the book.’

Second: Great! Very good improvement.

Third: These things happen. People get sick, and, of course, to some degree every decent human being understands.

You say that ‘you let the stakeholders know.’ To me, depending on exactly how you did it, it is a potential weak point, or area for improvement. For example, if you ‘just’ sent an email, and they never read emails, then this is not very good.

Here’s what I suggest.

The PO should sit down with the Business Stakeholder (and any key managers) and discuss the project.  Help them understand that we expect to make progress every Sprint, but that the long-term success is key, not that we ‘hit or exceed’ each and every Sprint. Stuff will happen, and we will have ups and downs.

You want to keep them informed. When and how should I inform you about impediments in the Sprint that mean (or might mean) that a given story may not get done (done, done) in that Sprint?

There are lots of situations. Sometimes they will say: ‘Don’t bother to tell us until the Sprint Review.’  They might say: ‘Text me immediately.’ Or other variations.

Discuss the business purpose or impact of informing them, or inform them sooner or later. For example, if you are lacking something and those people might get that ‘lack’ fixed (maybe knowledge, maybe a screw, whatever), then informing them quickly could be very helpful, but, if they cannot do anything with the information, why bother? So, discuss this.

Discuss also how much detail they need on some sample impediments like this that have happened.  Sometimes they want to know, but without much detail. Sometimes they may want more detail and having the detail would actually help.

Let’s say you agree to inform them by email ASAP with a special subject line (so it sticks out in the inbox), and usually in not more than 30 words.

Now, also talk about how these impediments will be discussed in the Sprint Review.

Probably agree that the PO should not assume that the business stakeholders or managers read the emails.  Likely they did not read them, or forgot about them.  So, to some degree (ask how much), these impediments need to be mentioned and (lightly?) discussed in the Sprint Review.

As you see, I am proposing a working (living, changing) collaborative relationship between the team (PO) and the Business Stakeholders (and/or managers).

The key goal is to make that relationship more effective. This ‘inform about impediments’ issue is just one discussion point in that relationship.

Put another way, the answer to your question partly depends on where that relationship is and can be about now.

One more thing. The team (the whole Scrum Team) is always expected to work together and overcome impediments (in priority order) where possible. So, at some point you might need a discussion of other impediments, of what the team (SM?? Others?) did about them, etc. After some trust is developed, maybe all of this does not need to be explained every time, but the key idea is: You can’t just say ‘I have an impediment, sorry!’ The team has to always be trying to overcome the top impediments.

In this case, what might that mean? Well, maybe someone in the team could help out with the design, or the team borrows a ‘chicken’ or another chicken to help out with the design, or at least went to a manager and asked for advice on this one. Depending on the situation, this might need to be discussed. At least there needs to be a discussion of, “OK, but what happens now? What do you recommend? Is he well now?” Or, “Next man up!” Or, “What?”

Long enough answer for today.

Please tell me if you want to give more information and/or ask it a different way.

BTW, I am fairly confident that you (Tony) did the right things. In part my answer was for others, others less experienced and successful with Scrum, you might reach the wrong conclusions if I had not explained more.

Facebooktwittergoogle_plusredditlinkedinmail

« « Multitasking || “It’s a mixed up muddled up shook up world” » »

Tagged:

2 thoughts on “Question: Explaining Impediments to the Sprint Goal that happen

  1. Tony

    Hi Joe,

    I think it is definitely fair to question, “How have you increased your velocity so quickly? Is this velocity, real? I mean, really real?”

    To be very honest, I think it is! The change has been in breaking up stories smaller and smaller, and getting really good user requirements for those very small stories. That has been the reason for the quick change, in my opinion.

    The first few sprints, I was throwing stories out all together from the sprint that I felt were not defined well enough, and then substituting it for a more clearly defined story. When the stakeholders and PO realized this was happening, because I would inform them of these changes, we really improved our story writing.

    Back to the main point, I guess the main impediment/excuse is we are a smaller company. Which prevents me from plucking chickens (ha!) from other teams. The solution has to be developing skill sets for other team members to become better designers, or bring in more designers (cost). My solution probably lies in the developing skill set area, but that hearkens back to what you said on trust. Trust also has to be developed for us to prevent this issue in the future.

    The way I informed the stakeholders and PO is during what I call our “production meeting.” I use this meeting as a once a month let’s start thinking about stories for the next release (the one after the one we are working on). We do these with different departments (Sales, Client Engagement, Support, etc.) to get them more prepared for the Agile Release Planning meeting. When I realized what was happening with design staff, it just so happened to fall in the same week as these production meetings. I just told each of them in those meetings, that I didn’t feel confident on specific user stories due to that impediment and they likely would not be complete this sprint. I also, told them (like you mentioned) that we would revisit it in the review. I just thought, “does bad news get better with age?” With that thought in mind, I decided not to wait until the sprint review.

    Reply
  2. Joe Little Post author

    Thanks Tony.
    For others, there is a strong linkage between higher real velocity and smaller stories, as Tony said.

    Hmm. Maybe I should do a post on what to do if you are ‘missing a skill set’.

    Lastly, guess what? I like your question: does the bad news get better with age? (smile) IMO, it is something we do not ask often enough.

    Regards, Joe

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *