Quickest scrum implementation

Is the Product Owner receiving sprint increments he or she genuinely cares about, and can release and put to use?

You can search Google to find it

If you keep changing the sprint duration, it will create problems for team. Also I agree with Ian's comments, are you guys doing it as a part of your Scrum class or really started practicing Scrum in your project/product.

Your stakeholders may not see any value in your development effort and may not be part of it.

I would recommend to start with One week sprint cycle.

Ian,
yes, team works on real requirements. It's a web development field.

Sanjay,
could you be more specific - what problems will it create?

One week sprint length is achievable within 2 weeks. Also, there could be a shortcut from 1-day to 1-week, once 1-day sprints are working well. In this case this exercise might take only ~1 week.

If the team are able to sprint on a daily basis, so that they deliver increments of value that achieve a meaningful Sprint Goal every day, and if the PO is in a position to release that value every day, then why lengthen the sprint?

Why batch work up more that you have to? Why change what appears to be a productive and viable cadence? Why are you aiming to defer delivery into production by up to a month? Why put the release of value in delay, and reduce the team's opportunity to inspect and adapt using the release-quality feedback you can presently obtain?

I am scratching my head as well.

You make reference to what is almost the "holy grail" of Scrum, which are 1-day sprints resulting in potentially-releasable software.

Why would you then consciously choose to regress your Scrum practice to a less-than-ideal state by increasing your sprint duration?

As an aside, you want to settle on a fixed sprint length, so that a predictable velocity can be established. Such a velocity can be used both by the team to determine an appropriate amount of work to accept each sprint, and by the organization to forecast potential completion (release) points within the product backlog. Every time the sprint duration changes, you have to start over.

Others have touched upon the "beauty" of shorter Sprints in terms of value it could deliver in taming the complexity.

So I will take your question: "What could be risks in such approach? "

There are three things you may want to monitor and ensure they are taken care:

1. Is there a genuine need for the Product Owner to limit business risks that require them to have increment every day for inspection? Is there genuine need for the business to deliver the value at this lightning speed? While there is value in having this dramatically shorter duration, it may effect shocks in the organization to absorb them at this speed

2. Does it still accommodate the need of the Development Team to synchronize the development work with larger organizational ecosystem?

3. As the Sprint duration gets shorter, the cost of the Sprint Events may proportionately increase. For example, even for one day Sprint, you still need to have all four events. Though they may be shorter, how much of an impact these events will have and how much time is left for the real development work?

- Musthafa (Scrum Narrative and PSM Exam Guide)

Thanks for your replies!

@Ian, you wrote:

If the team are able to sprint on a daily basis, so that they deliver increments of value that achieve a meaningful Sprint Goal every day, and if the PO is in a position to release that value every day, then why lengthen the sprint?

Two main reasons:
1. PBIs taken into the sprint were pretty small. It was this time in SDLC when users give tons of feedback consisted of small changes. It is impossible for some PBIs to deliver them within 1 day.
2. 1-day sprint is exhausting for the team. At the and of a day they said they feel brainwashed.

@Timothy, I believe I answered your question answering Ian's? Let me know otherwise.

@Mustafa,
valid points. Your point #3 is something that I noticed as well.

My intent for so short sprints was to learn mechanics of Scrum primarily. Develop habits. Reduce WIP and keep focus. It worked pretty well in a team I worked with, and I'm curious if that's an exercise that could work elsewhere. For the record, we did 2x 1-day sprints and then moved to 1-week. I know it's not much data, but it did it's job in my case. I'm wondering if that's repeatable in other environments.

> Two main reasons:
> 1. PBIs taken into the sprint were pretty small.
> It was this time in SDLC when users give tons
> of feedback consisted of small changes. It is
> impossible for some PBIs to deliver them
> within 1 day.
> 2. 1-day sprint is exhausting for the team. At
> the and of a day they said they feel
> brainwashed.

I think you've answered your own question. Those are the risks. The approach you have outlined for daily sprinting is not sustainable under the normal conditions of value delivery. Try to keep it up, and it could break the team.

Choosing the right cadence is important. It has to balance the ability of the Product Owner to articulate business value, and the ability of the team to deliver it in a sustainable, predictable, and releasable way, each and every sprint. Learning to sprint to the right cadence is not a mechanical process of putting new teams into a meat grinder, and then gradually easing off by turning the handle more slowly. There is more of a science to it than that.

A case *can* be made for compressing a Sprint in order to maximize the inspect-and-adapt learning opportunities available to a non-performing team. I believe Jeff Sutherland has done something along those lines with his "Shock Therapy" approach...but even then the Sprints were a week long.

Thanks!