Scrum Situation - Opinions Wanted

#1

I have a situation with my team would like some advice from the coalition.

We were working on a submitting a build for the recent iOS 10 release. It took us a longer than we expecting to get it out the door.

The next priority item from the P.O. is a web service migration. The web service we use to log users into the app is being depreciated by our company and we need to move to a new version. Everything will operate in the same manner for users, we just need make this change under the hood.

We have an 8-point, technical story to capture this work. It would take about 5 days to code and 2 days to test before we can get it in front of our P.O. for acceptance. There are 5 days left in the Sprint.

What are my options as Scrum Master?

#2

Ask the team to provide at least three options that they think would be viable.

Seven if you really want to push them along the path :slight_smile:

SM to SM conversation/questions:

  • How big is the team?
  • How close to Done is the iOS 10 release?
  • Would starting something new before finishing iOS 10 be a WIP violation? A big context switch?
  • Can you split the 8-point technical story into smaller pieces?
#3

Answers:

  • 2 iOS, 2 Android, 1 QA
  • iOS 10 release is DONE, 8 point ticket is only thing left in the Sprint backlog. Other iOS engineer picked up a small 3-point feature to finish out the Sprint after the iOS 10 release. Android is on track to finish their batch.

This situation happened a few days ago. We ended up using your story splitting methods and created a Spike for him to work for the remainder of the Sprint, hoping the research will help us break the 8 point story down into smaller technical stories for the next Sprint.

This is actually the situation where the team suggested the switch to a scrum-ban approach after about 90 minutes of hashing out the options.

The reason I wanted to propose this to the coalition is because we always seems to be caught in this situation. There’s 3-5 days left in the Sprint, all work is code review, testing or acceptance and an engineer frees up. We always end up pulling in a new ticket knowing it will not be finished and being okay with carrying it.

#4

Not the answers you’re looking for, but what I feel are truly meaningful to helping you overcome the problem:

  • Fitting “too big” into “small enough” is not a matter of “options” for the SM.

  • A “spike” for someone to work in isolation–worse, to fill time–is not a spike. What is the risk of knowledge confined to a single team member?

  • The systemic causes are very evident to me in your last paragraph (from reply, above). What do you see? What holds this pattern in place?

#5

Thanks Zach, I definitely would like to hear you expand about this some more! These are the answers I’m looking for.

  • I should have said, what are the team’s options? We always seem to have 2-3 days left in a Sprint with all of the work completed, but not enough time to start something new.
  • What is your definition of a Spike? To my team - it’s a time boxed effort to do some research that will result in more stories. We know we have to change the authentication services under the hood, so we created an 8 point technical story to do all of that work. The Spike was for him to spend the next few days understanding what architecture needed to be changed so we could possible break that 8 point story down into smaller chucks. We also don’t normally pair or put the whole team on a Spike, one member normally does it and briefs the rest of the team, sometimes creates a wiki page if needed, etc.
  • What is very evident to you from my last paragraph? We don’t leave those items in Code Review, Testing or Acceptance. As stated earlier, we get all of the work through Code Review, Testing and to Acceptance for the P.O. with anywhere between 1-3 days left in the Sprint. What are we suppose to do when there are 3 days left and no work and the next item to pull in is more effort than the allotted time left.
#6

My insights for you. They represent one way. There are many ways, though (I say this to suggest there is nothing critical in my response… things can get sideways easily over text/documents).

I consider a “spike” to be a clever name for learning. I also believe that programming is mostly, say ~90%, thinking about what decision to make (of many options). The goal is to use software in that decision, as only then can we truly know what we need about the work. Thus, a spike is time for a team to perform thinking, some programming, and experimentation, to agree on a decision.

A spike given to a person to do research smells like “lead programmer” behavior, coupled with the decision making process confined to a single person. The collective knowledge of the team is not leveraged. A wiki or “report” to the team is less effective in conveying knowledge, compared to the experience of working on the code.

Regarding your last point, I may have misunderstood. I interpreted your scenario as all the work “in testing” at the end of the sprint with “developers” free. If that’s not the case and you have a few days open, can a backlog item be sliced to complete it?

If not, I don’t see the value in starting it. After all, unless you’re releasing continuously in a sprint, starting work now won’t cause it to be released any sooner (it will still be “done” at the end of next sprint). While, if the former, I question why you’d work in sprints anyway :wink:

If an item can’t be sliced, practice it with intent to finish. We can always slice… but it’s a skill that requires practice and discipline. Else, why not do some refactoring, or look back on your automation for the sprint? Heck… do some side projects for a couple days, then. I’d rather have a team with 100% energy going into a new sprint, rather than 99% energy.

Again, this is just one way, though.