2

we're working with a popular website platform vendor, which is a great platform for building websites, and they have a vibrant community of third party vendors who integrate with their platform.

However, this vendor apparently does not have a checklist, acceptance criteria, that a plugin must contain in order to be accepted into their marketplace. As such, the team has worked on this for several months, with the plugin getting rejected and a new "checklist" being produced by the vendor.

The vendor refuses to produce a definitive, final checklist.

Since we're implementing Scrum in our organization, and for many of us it is our first time actually using it, I'm trying to understand more about how to handle items of great uncertainty. If we commit to "Integration with website vendor X's marketplace", and we continue to fail to deliver this in our two week sprint due to forces outside our control, how should management and the team look at this?

  • Does it mean the team didn't complete what it committed to?
  • Wouldn't this be considered a "failure" to deliver what was promised?

Since this item cannot be estimated for a 2 week sprint, how would the team deal with this?

  • Should the team just keep recycling this back to the product backlog and selecting it again for another sprint, knowing that the velocity for this particular item won't be counted until it is done?
  • What do you do in cases of such extreme uncertainty due to a third party vendor's inability to clarify requirements?
Improve this question
5
  • I'm not understanding how this impacts your sprints or your release schedule. Can you expand on that a bit?
    – Todd A. Jacobs ♦
    Jun 11 '15 at 14:18
  • @CodeGnome - I'm trying to understand Scrum while simultaneously implementing it in our organization. I clarified with an edit in the 2nd to last paragraph. Basically, if the team can't deliver what it commits to (i.e we will commit to integration with website vendor X's marketplace) and continually fails to deliver, how should management and the team look at this? Doesn't this mean the team can't deliver what it is promising? Or am I thinking too "command and control" style management? Hope this helps.
    – jmort253
    Jun 11 '15 at 15:44
  • I think the point is that you shouldn't make commitments based on resources outside the team's control. This is a process problem. Let me think about it a bit before giving a more detailed answer, but in the meantime I wouldn't accept stories with those sorts of dependencies into a Sprint in the first place.
    – Todd A. Jacobs ♦
    Jun 12 '15 at 0:45
  • @CodeGnome - That would mean "integration with website vendor X" is impossible to get done if we're unwilling to try it. These are areas where I can see executives having major concerns.
    – jmort253
    Jun 12 '15 at 5:07
  • Also, I should add that we didn't know website vendor X was going to keep changing the requirement over and over again. On the surface it seemed like a reasonable thing to commit to doing, that is until the team started to work with them, and then there was "just these few other items".
    – jmort253
    Jun 12 '15 at 5:09
3

Scrum is the right process for dealing with such uncertainty

Imagine how you will deal with this if you were using waterfall. Any Gantt Chart you draw up will be obsolete before you create it!

Of course, it is a business decision how much additional effort you want to put into this. But, if you do decide to pursue it, here is how you should approach it using the Scrum process.

Since this item cannot be estimated for a 2 week sprint, how would the team deal with this?

Don't try to estimate the entire release in one big lump. Looks like you do have a checklist. Try to estimate each item in the checklist as a story. Schedule the stories that can be accomplished in a 2 week sprint, based on other priorities.

Should the team just keep recycling this back to the product backlog and selecting it again for another sprint, knowing that the velocity for this particular item won't be counted until it is done?

I won't recycle anything. I will work on the stories based on the checklist I have. I will submit the plugin when the checklist is completed. If I get a new checklist from the vendor, it is new work that has been discovered which will become new stories.

What do you do in cases of such extreme uncertainty due to a third party vendor's inability to clarify requirements?

As I said earlier, how much effort you want to invest into this is a business decision. No process can make such external factors go away. However, when faced with such extreme uncertainty, Scrum's motto of transparency, inspection and adaptation will be most suitable to handle it as well as you can.

Improve this answer
5
  • I see, so if they complete the checklist and meet internal acceptance criteria, you count the sprint backlog item as complete. However, what if this isn't something that's releasable to a user? There's no value here to a user if the vendor won't release the plugin to the market, so would it really be right to count the points as part of the velocity? Thank you.
    – jmort253
    Jun 11 '15 at 14:10
  • Yes. Velocity is based on delivering each story meeting all acceptance criteria and definition of done.
    – Ashok Ramachandran
    Jun 12 '15 at 19:59
  • @jmort253: There are always circumstances outside the control of the team that prevent the product from actually being shipped/released. That is why a spring should result in a potentially shippable product and not an actually shipped product.
    – Bart van Ingen Schenau
    Jun 14 '15 at 11:18
  • @bart not to get into semantics, but if the vendor refuses to ship it, I feel like that means it is not potentially shippable. Thanks for weighing in.
    – jmort253
    Jun 14 '15 at 11:20
  • @jmort253: As far as I understood, the reasons for not shipping are not known until the vendor sends back the refusal. This means that to the best knowledge of the team, you actually delivered a potentially shippable product and then were confronted with a new reality. I must say that this vendor is not being particularly helpful to deliver something, regardless of the process you use.
    – Bart van Ingen Schenau
    Jun 14 '15 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.