24 Hours for Development work
Hello there, The scrum guide mentions - Development Team plans work for the next 24 hours. [Link]
Wanted to know is there assumption that there are 24 Hours of development time available for the dev team per day? If yes, how is this assumption appropriate?
My understanding it's just referring to time in general.
For example...if we have the Daily Scrum at 8am every morning then we would be planning what will be done until the next Daily Scrum (8am the following day).
There is no expectation that the development must be available 24 hours a day.
@Tony Divel's answer is absolutely correct. To understand why, I suggest that you think outside of the Scrum Guide. But start in the Scrum Guide section that defines the Scrum Team (https://scrumguides.org/scrum-guide.html#team).
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.
Now, since we are talking about agile software development, go to the Manifesto for Agile Software Development's guiding principles (https://agilemanifesto.org/principles.html) and look at the 8th one.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Ask yourself if a self-organizing, cross-functional agile team would consider 24 hours a day development a pace that could be maintained indefinitely?
Are there situations where having a 24 hour window is beneficial? Absolutely but those should be be exception and not a rule. If the team finds they need it, then they should use it. But as a Scrum Master, Product Owner or Development Team member, I would heavily question why that need arose and how to prevent it from happening in the future.