One day Sprint
Recently I read a post about this topic, the posibility about one day Sprint. In this post the author remove some events like Daily Scrum and he replace it for a coffee break while talking, this is only an example about I read.
What do you thing about one day Sprint? Is this really usefull? Otherwise you think that it is not useful.
I don't really see how you'd do a one day sprint. What about retrospective, review, planning? I don't think you'd include a proper implementation of those into a one day sprint.
If you're talking about something like this:
https://medium.com/@gabriela_a/a-one-day-idea-generation-sprint-30f684f…
They might call that a "one day sprint", but in the end it has nothing to do with a sprint in terms of scrum, but is actually just a workshop day.
According to Scrum guide one Sprint is time-boxed in "one month or less" and the rest of events being adjusted proportionally. The framework don´t say nothing about shorten Sprint duration until one day.
It is ok that you could have one 4 minutes Planning, one 2 minutes review and one minute retrospective (We asume that Daily Meeting can spent 15 minutes or less).
I am sure (99%) that is not useful but... is it possible according the guide?
This is the article (it is not talking about Scrum) that I refer https://hackernoon.com/one-day-sprints-1ce1f53a08b2
How meaningful would the Sprint Goals be? Would they be likely to significanty de-risk the development of a complex product?
Technically It would be sprint indeed. but it surely contradicts the idea of scrum. I am not sure how would you build an MVP at the end of the day. It would merely be completion of task but NOT MVP. Sprint should yield something meaningful -adding a business value and in this case it may not.
According to Scrum guide one Sprint is time-boxed in "one month or less" and the rest of events being adjusted proportionally.
Not true. The events do not need to be reduced proportionately.
If it works, go for it; but as Steven has pointed out, it's difficult to imagine effective implementation of the Scrum Events in such a short timescale.
How meaningful would the Sprint Goals be? Would they be likely to significanty de-risk the development of a complex product?
Ian imagine that you have to launch initiatives for a marketplace like Amazon, for example, you have the goal to add the functionality that allowing you to add an article to a wishlist (like an experiment to receive feedback). To have more context imagine that you are a part of an innovation team.
Your goal is "Add articles from the marketplace to a whislist" and you can make it in a day.
Not true. The events do not need to be reduced proportionately.
Totally agree.
If it works, go for it; but as Steven has pointed out, it's difficult to imagine effective implementation of the Scrum Events in such a short timescale.
Simon this is not a challenge I am only trying to understand where is the constraint to not doing this kind of Sprint becasuse according to the guide I have not found a refusal to put it on practice.
To have more context imagine that you are a part of an innovation team.
Your goal is "Add articles from the marketplace to a whislist" and you can make it in a day.
An MVP test may be framed accordingly. However, there might be too many unknown unknowns to justify an immediate Sprint commitment. In other words, it wouldn’t be a matter of “you can make it in a day”. Rather, the team would have to make it in a day (or less) because their context would be too volatile to support any greater leap of faith. A good, efficient MVP would ideally consist of just one quick test. If for some reason they tried to sprint at such a time, that would be the scope.
Scrum typically finds its sweet-spot once a domain ceases to be chaotic, and a complex product has been identified for which there are known unknowns. At that point, a team can commit to a significant goal for which multiple backlog items may be actioned, over a period lasting up to a month, and for which a Sprint forecast makes sense.
What do you thing about one day Sprint? Is this really usefull? Otherwise you think that it is not useful.
Benjamin - What would be your Scrum Team's objective? Some questions to think about.
- Does your Scrum team need to plan for new work on a daily basis? If they ran a 1 week Sprint, they could use Sprint Planning at the start of the week, and the Daily for planning out each day. The Daily is your Development Team's planning session.
- Do your stakeholders need to give feedback on the Increment on a daily basis? Or can they wait 5 days? Are your market conditions changing that fast that you need to meet with stakeholders? Would they even be available on a daily basis?
- Is risk a factor? Does the risk mitigation of a 1 day Sprint outweigh the cost of the overhead of the events?
- Does you team need a formal event to continuously improve? While there's an event for that (the Sprint Retrospective, no one needs to wait until the end of the Sprint to improve a process or work out an issue).
- Do you need to release on a daily basis? You can still release daily, even more frequently (like Amazon - in seconds). You don't need to wait until the end of a Sprint.
My final thoughts - you have to weigh the benefits of using the Scrum events on a daily basis against the cost to run the meetings. In most cases holding the events daily would be overkill. Shorter Sprints such as 1 week Sprints tend to be more costly because of the additional overhead of the Scrum events. One day Sprints would be extremely costly because of the overhead, plus they would have to refocus every day so it's a bad idea.
Well ... 'sprint' in wider sense may IMHO denote time-boxed goal-oriented conceptual / prototypicing exercises - and I have been in quite some singular explorative design thinking workshops (1..2 days) that were understood accordingly. but as for those - how valuable in actual case ever - I would not claim them to be scrum implementation per se. maybe such one-day-long 'mini-sprint' exercises could be a way in which self-organised DT can accelerate progress in working towards a mutual scrum sprint goal (in narrow sense)...
An MVP test may be framed accordingly. However, there might be too many unknown unknowns to justify an immediate Sprint commitment. In other words, it wouldn’t be a matter of “you can make it in a day”. Rather, the team would have to make it in a day (or less) because their context would be too volatile to support any greater leap of faith. A good, efficient MVP would ideally consist of just one quick test. If for some reason they tried to sprint at such a time, that would be the scope.
What is the difference between developing that MVP test and a Sprint commitment is this case?
Scrum typically finds its sweet-spot once a domain ceases to be chaotic, and a complex product has been identified for which there are known unknowns.
Why is that, do you think? Is ceasing to be chaotic (the associated discovery period) not, then, a preliminary phase of some kind before Scrum is best suited?
What is the difference between developing that MVP test and a Sprint commitment is this case?
There’s nothing to stop a team from committing to the test of an MVP. However, that test would very small and ideally atomic. There would be no corresponding forecast of work to inspect and adapt. As a rule of thumb, it would be quicker to execute the test than to plan it. Hence the rationale for a Sprint, with a forecast of work to inspect and adapt in order to meet a goal, would not be there. Its purpose would be too attenuated.
Why is that, do you think? Is ceasing to be chaotic (the associated discovery period) not, then, a preliminary phase of some kind before Scrum is best suited?
The short answer is yes. The domain must be sufficiently stable for empirical process control to be established.
The principle of having shorter Sprints at the chaotic/complex boundary is a sound one. However, a one-day Sprint is unlikely to present enough of a forecast to make the overhead of running one worthwhile. It would be better to act-sense-respond and see if any hypothesis holds.
If and when the domain is reduced to a “merely” complex one, a Sprint can then be used as a probe to drive emergence.
Because there is a need for a one-day Sprint (in which a Goal needs to be met within one day), it suggests that the domain is so chaotic that a Sprint (in our case, a Scrum Sprint) is not suitable. The overhead of a Sprint, the lack of a substantial forecast, etc. all play a part.
However, the concept of meeting an objective, or a goal (lowercase) of some kind within one day (a time-box) is still, as you say, a sound plan.
That isn't to say, though, that Scrum can't work in a chaotic environment in which a goal is not needed so urgently; chaotic domain's are not limited to daily persevere or pivot decisions, correct?
Scrum can be made to work in a chaotic environment, but is unlikely to prove a sensible choice. Empirical process control would not be possible. The rules of a chaotic domain are unknown, making it impractical to inspect and adapt beyond the scope of what might be afforded by a very brief test.
It’s possible to have a chaotic domain where the elicitation of feedback for even a brief MVP test will take longer than a day. However, that won’t help to establish empiricism...it will just take longer to do so and perhaps cost more. That’s why it’s so important to choose MVPs carefully, identifying leading indicators and eliciting actionable metrics as rapidly as you can. This is a critical skill in innovation accounting.
I see. Perhaps my understanding of a chaotic domain isn't great, or I've misunderstood your comment here:
Why would an innovation team in search of a sustainable business model not fall within in a complex environment? Is it because a complex environment assumes a product exists or is that the MVPs within a chaotic environment are not yet really the product but as you say, solely tests providing some leading indicators that such a product will be valuable?
When we talk about what is needed to begin product development with Scrum, we rightly tend discourage project initiation phases, Sprint 0s, etc. but we don't discuss bringing an idea from a chaotic one to a complex one.
Why would an innovation team in search of a sustainable business model not fall within in a complex environment?
Hopefully it would, but the team probably won't get the chance until later. That's why I italicized immediate. An innovation team will first try to bring a domain under empirical control so a value proposition can then emerge.
The skills required to bring chaos under control, and to then deliver a complex product or service, are different. It can help to distinguish between:
- a discovery team, consisting of innovators (e.g. from a product ownership guild) who parse new opportunities out of the seemingly chaotic by means of very small and user-focused MVP tests
- an innovation team proper (such as a Scrum Team) which would then work on a complex proposition so established
- an acceleration team (such as a DevOps-focused team) which masters lean delivery and flow once the complex becomes complicated
I understand. Thanks!
Supossing (based in example) that you are in Amazon you already have a market, and you can have a Scrum Team dedicated to innovation and delivering new features to test with customer feedback.
In this case you are not in a complex environment then you are in a complex.
Supossing (based in example) that you are in Amazon you already have a market, and you can have a Scrum Team dedicated to innovation and delivering new features to test with customer feedback.
In this case you are not in a complex environment then you are in a complex.
My final thoughts - you have to weigh the benefits of using the Scrum events on a daily basis against the cost to run the meetings. In most cases holding the events daily would be overkill. Shorter Sprints such as 1 week Sprints tend to be more costly because of the additional overhead of the Scrum events. One day Sprints would be extremely costly because of the overhead, plus they would have to refocus every day so it's a bad idea.
Chris I agree with you. Can we conclude that according to the guide one-day-sprints is possible but not recomendable?
Well ... 'sprint' in wider sense may IMHO denote time-boxed goal-oriented conceptual / prototypicing exercises - and I have been in quite some singular explorative design thinking workshops (1..2 days) that were understood accordingly. but as for those - how valuable in actual case ever - I would not claim them to be scrum implementation per se. maybe such one-day-long 'mini-sprint' exercises could be a way in which self-organised DT can accelerate progress in working towards a mutual scrum sprint goal (in narrow sense)...
Matthias If you aren't delivering an increment that producing value at the end of the Sprint you aren't practicing Scrum. Are prototypes valuable? Are it adding value?
In my opinion, the Scrum Guide is actually pretty clear that a sprint cannot have a duration of a single day:
... enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.
... The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours.
... Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
In addition, the very title "Daily Scrum" implies that it occurs on a daily basis within the sprint. As it is a key inspect and adapt meeting, it must be able to inspect something.
All of this points me to a conclusion that a sprint must be longer than a single day, and at a minimum be at least two days in length. I will also agree that such a short duration is not at all recommendable.
Thank you so much @Timothy this is the kind of answer that I was waiting. Clear and concret and based on the Guide