Can I start a new sprint without deliver the last one?

Last post 05:27 pm September 11, 2019
by John Varela
7 replies
Author
Messages
06:46 pm September 5, 2019

I'll try to simplify my questions and avoid story telling.

 

1) Can I start a new sprint without delivering the last one?

2) During sprint 2 can I change or add items in undeliverable sprint 1?

3) How many undeliverable sprints can I have in my product?

 

I am facing a flexibility problem where the client says that he can change the framework any time and in any way he wants. He argue that scrum predicts flexibility.

I'd like to know if there is a 'scrum way' to deal with this cause in the scrum guide I didnt find really.

 

Thanks advance.

07:01 pm September 5, 2019

Sprint's are time boxed. If nothing was delivered as a result of Sprint 1 there are formal inspect and adapt opportunities within the framework that would allow that to be made transparent if it wasn't already. 

If the work in Sprint 1 wasn't delivered but is still desired is there a reason you wouldn't try to deliver it in Sprint 2? 

07:33 pm September 5, 2019

My client has 12 sprints planning already. Like a roadmap. And in his point of view another sprint can start even if the last one wasnt published. In that way the delivery date of the product will be in time. For me it doesnt make any sense. I understand he is concerned about the delivery date. But I think that for scrum only one sprint can be active at time and I cant handle two or more paralel sprints with the same team. Is that right?

08:29 pm September 5, 2019

Why would the Development Team forecast two Sprint Backlogs at the same time? Do they really believe they can commit to two Sprint Goals? If not, why would they agree to such a practice?

08:39 pm September 5, 2019

By "Deliver" do you mean complete or released? Each sprint you're supposed to build an increment of working software so if you're not completing an increment and just stashing it away and moving onto another; when do you complete increment #1? If you're not completing the preceding increments, how do you know the following increments will even work properly? 

All due respect, your client is doing rapids, not scrum. He just wants to do short versions of waterfall.

09:24 pm September 7, 2019

If a development team member decides to be stubborn and does not want to listen to anyone, what should scrum master do after having done everything humanly possible to bring him to reason? What is the last action a scrum master can take?

12:16 pm September 9, 2019

@Benjamin, 

Here's an interesting read by Christiaan Verwijs with the Liberators related to your question. 

https://medium.com/the-liberators/myth-the-scrum-master-cant-remove-people-from-the-scrum-team-92fba0ad391b

I would recommend something like this only as a last resort. Some earlier tactics could be: 

  • Listening and understanding their objections and point of view
  • Focus on 'what' needs to change and not 'how' 
  • Remove barriers that are causing the behavior
  • Show tangible benefits to changing behavior
  • Have someone they respect talk to them - could be another peer they've worked with for a long time
05:27 pm September 11, 2019

Attempting to assume someone can effectively build 12 Sprints and assume all the details are known and no changes will be made/missed, is Waterfall. If work needs to work that way, Sprints will make it harder than just setting a milestone delivery date instead. Scrum would lead to distraction rather than dedicating to pure Waterfall, so I would recommend assessing why Scrum?

The reason someone would choose Scrum specifically, is to create predictable delivery of expectations (as opposed to predictable delivery dates).

It's also worth mentioning that the end of the Sprint is not a delivery date. Ideally you'd want to deliver each item as soon as they are done and PO approved.

Most of the time it's delivered to a Staging (mock-production) environment until all dependency pieces are done and then it's released to customers. That release process could exist within the Sprint to help allocate team load/capacity and prevent overloading anyone, but otherwise that process ideally would be Sprint agnostic.