1

One of my colleagues says that few e-commerce companies follow a single day agile sprint cycle, as at times they have to be competitive in terms of feature releases and launch new sales campaign, etc. He adds that there is an R&D team in such companies, which sets the daily development target and that target gets QA/release on daily basis.

What I understand is doing a daily sprint might be too difficult, as in the same time there needs to be regression/build/sanity testing and a sprint cycle should be long enough so, that developers also have time to re-fix the bugs reported in the sprint. And in general companies follow a sprint cycle of 2-3 weeks and companies which have good amount of automation for QA and Continuous Integration tools practice do follow a single week of sprint cycle.

Please advice if a sprint cycle can be as long as 1-3 days?

Improve this question
1
  • 1
    There's too much overhead in formal Scrum for that. However, you can have other agile systems that have 1-3 day cycles times. – Todd A. Jacobs♦ Jan 12 '16 at 15:58
3

Yes, it's OK to have iterations that are shorter than a couple of weeks. Some companies do this - according to this ThoughtWorks blog post, Amazon has the capability to push to production more frequently than every minute, Facebook releases to production twice a day, and Google may update some of their services twice a week.

If you leaned out your process, you could (in theory) achieve a continuous flow of work. At the start of the project you have a backlog of new features, defects, and enhancement requests that is constantly being prioritized by a product owner-type role. As soon as an engineer has the work capacity, work items are pulled off and go through the development cycle. As soon as a change has been properly vetted, it can go live. Depending on the size and complexity of the work item being implemented along with the project's activities, it could go through the process in less than a day. At this extreme case, though, you don't have iterations anymore.

Improve this answer
4
  • Excellent article by Humble. I'd add a clarification that what Thomas has proffered; separate a "Sprint" from delivery in your mind. Sprint is a Scrum term; it's a timebox of 30 days or less during which potentially releasable software is produced. The choice of when to release should be up to the business and is enabled by sound, technical practices. The overhead of a 1-2 day Sprint is probably not worthwhile in most circumstances. You can read more on Scrum here: scrumguides.org/scrum-guide.html – jason.t.knight Jan 11 '16 at 21:49
  • that said, delivery is a different aspect and sprint is different thing which is more focussed on planning, demo, retrospective and other ceremonies than delivery? – prasun Jan 12 '16 at 3:46
  • @prasun In Scrum, sprint is another word for iteration. It includes whatever ceremony you have deemed necessary. In textbook Scrum, it's a backlog grooming, sprint planning, daily stand-ups, sprint reviews, sprint retrospectives. You can tailor the process to what works for you - a choice between a backlog grooming meeting after the sprint review or continuous product backlog grooming by the Product Owner. Delivery is just the act of getting the software to the users - packaging it, putting it up for download, pushing it to production, however you make it go live and let users use it. – Thomas Owens Jan 12 '16 at 12:58
  • @jason.t.knight I agree that the full overhead of a 1-2 day sprint isn't worth it. But by the time you're having iterations that short, you are probably doing more things just-in-time. For example, you have gone from having retrospectives at the end of the sprint to some kind of continuous feedback cycle for the process and environment. You've probably also eliminated your product backlog grooming meetings and you're probably continuously grooming the product backlog. You've probably eliminated your sprint planning meeting and simply work the backlog like a queue. – Thomas Owens Jan 12 '16 at 13:01
3

Actually, the automation does not necessarily has a correlation to the length of a sprint. It more likely that some teams can plan further ahead than others.

The problem with the very short sprint is the overhead of Scrum practices such as planning, retrospective, and demo. These meetings are important but takes time. A 3-day long sprint as about 25% waste. That's hard to sell.

The next problem is the demo. short sprints means more demos. Can you demo every time something that's worth the time of the stakeholders? Are the stakeholders always available?

The third problem is the retrospective. Is it possible to implement an improvement in such a short time?

If a team is able to pull of a short sprint, it may be a good idea to start experimenting with frameworks that support continuous work over iterative, such as Kanban or Lean.

So rather have short sprints, start working continuously, but that will require changes in your organisation.

Improve this answer
1
  • automation is not necessarily but, in software development it might be required in most cases, to make faster releases to production with negligible waste time – prasun Jan 11 '16 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.