Deadlines - Scrum / Agile
Hi,
I am a scrum master and have been told that we need to hit a deadline with certain scope.
In turn to meet this deadline the team have created a plan (similar to Gantt chart due to dependencies) with me facilitating. It is split into what we intend to carry out in the next four sprints to meet the deadline.
We have then reviewed this and adjusted this in refinement. In planning the team agree whether they are ok take what has been selected in the sprint.
The team are self organising as they choose what they can take into sprint. Scope has been reduced to focus one the product needed in the deadline and will be dealt with later.
Deadlines exist and will probably always exist.
Please advise on your views above to discuss from an agile / scrum perspective.
Thanks
I have an opinion on this but wasn't sure how to state it. So I did a quick google for "scrum deadlines". There is a LOT out there on the subject. In the top 6 listings that I read they were able to say what I thought really well. I'm going to point you to this one which can be found on this very site.
https://www.scrum.org/forum/scrum-forum/25794/what-happens-deadlines-sc…
That one starts with some really good explanations of how Scrum deals with deadlines. The discussion drifts a bit towards the end but even the "drift" is still relevant.
This one has very similar position as the first I gave you. https://medium.com/@teunhompe/scrum-loves-deadlines-an-end-to-the-holy-…; I really like this quote.
Let me get that one out of the way quickly: all Scrum practitioners love deadlines. They even impose a deadline upon themselves every two, three or sometimes four weeks. Why? Because you know it works! It forces you to focus on the stuff that really matters, compels you to prioritise and your work and motivates you to get stuff done. Yup, that’s right, the end of your sprint is a deadline.
As I said, there are a lot of resources on the net that describe how Scrum and deadlines co-exist. But in all I read it basically comes down to convincing the person(s) setting the deadlines that it can be met but they will have to flexible in the other parameters. And they need to be ready to invest their own time in the process in order to help course correct in order to deliver the value/functionality that is actually needed instead of what they think is needed at the beginning. Ensure them that they will be receiving increments of the value as the "project" progresses instead of having to wait until the end. Also let them know that at any point in the process they can say "this is enough" or "this isn't going to do what we wanted". That is the beauty of the incremental delivery approach. You don't have to wait until the deadline to know if your money was wisely spent. You get the option to stop early and save money, change the scope of what you want without having to spend more money, or continue on past the deadline but do it while receiving incremental increases in the value that you have already received.
Deadlines do exist whether we like it or not. The trick is to reset expectations on how that deadline is meaningful.
I am a scrum master and have been told that we need to hit a deadline with certain scope
What advantage would the use of Scrum bring in this situation? Why has the framework been chosen?
"Deadlines exist and will probably always exist."
You're quite right.
The traditional way of working (Waterfall, as it's called) most always keeps the Scope, Time & Cost fixed, and the Quality variable.
Agile keeps the Time, Cost, and Quality fixed, and the Scope variable
Do you see the differences between these two approaches?
"I am a scrum master and have been told that we need to hit a deadline with certain scope."
I can understand that. Been there, done that so to speak. Is that "certain scope" the MVP? Because at the end of the day, of every single day I should add, it's a question of resources.
If you have empirically demonstrated that the certain scope is an MVP (which, I should state, should be kept flexible, in light of future discoveries - product itself, market conditions, competitors' actions, etc), then all good. But is the team capable of reaching that deadline with most of the scope (MVP - which, I state again, should be flexible)? How do you forecast?
Lots of questions I can ask here, but I think the main one to be asked is Ian's.