Agile release cycles: every three weeks bad?

4 May 2010 - 8:00am
6 years ago
7 replies
2021 reads
jeff noyes

My company releases software after each iteration. The result is a constantly changing platform. I suspect this is really bad for the user experience. Anyone have usage data, case studies, etc on this topic?

-- Jeff Noyes Director of User Experience | Acquia 978.296.5237 | @jeffnoyes


4 May 2010 - 8:24am

Hi Jeff,

It sure sounds like a lot. But I think there is ultimately no certain way to respond to your question about optimal release cycles. So many factors are involved in terms of market segment, software complexity and process quality that any guideline will certainly be misleading to most. I personally work on a large software suite that is released every 6 months. This is done mainly to support the fact that no client within a 1 year update frame on an individual installation will have no more than 3 different versions to maintain, and also to have concentrated stabilisation periods for each release. We still do internal deliveries with the 2 or 4 week sprint cycles 'as per Agile'. These deliveries are mainly aligned with feature packagages that are testable and presentable and has a clear vertical cut through the architecture layers.

So maybe that's the only real answer to your question: In agile, there is a difference between the sprint deliviries and the public software releases. They don't have to be the same. But you just need to put mechanisms in place than will allow your stakeholders to review the 'internal' deliveries in some way, to adjust the direction your development is taking.

4 May 2010 - 11:30am

I have no actual data but it doesn't seem like it would be that hard to gather. The question I have though is what do you suspect makes it bad?

It could be that the pace of change makes it hard for people to learn, or the pace of development doesn't allow for actual in-depth design, or maybe you feel more research or testing are needed...?

Each of these sources of possible "bad" suggests solutions, and I believe it's possible to do good design in a rapid environment so long as you address the root causes.


On May 4, 2010 11:54 AM, "jeff noyes" <> wrote:

My company releases software after each iteration. The result is a
constantly changing platform. I suspect this is /really/ bad for the
user experience. Anyone have usage data, case studies, etc on this

Jeff Noyes
Director of User Experience | Acquia
978.296.5237 | @jeffnoyes

5 May 2010 - 1:11pm

I also wonder what would make it "bad".

Last summer I was lucky enough to catch Jared Spool give his presentation about Amazon and he pointed out how they are continually making minor UI changes. This makes many people feel that Amazon "hasn't changed their design" which makes them comfortable when they visit Amazon in spite of the fact that Amazon is constantly changing it piece by piece.

Point being: there are definitely good and bad ways to handle frequent deployments but at least some organizations are really successful with it.

4 May 2010 - 4:58pm

I managed a web app product from scratch through launch and a year and a half of development (don't ask where it went after that =]), and we eventually settled on  

  • Daily releases for tiny improvements and bug fixes which affected very few members
  • Weekly releases for low-impact new features that we had promised, people had asked for, and didn't fundamentally require relearning the app, and 
  • Monthly releases for large-ish features like billing, event management, new messaging system, etc.


After our 3 month launch, we eased down from monthly releases, to every two weeks, to weekly, to daily, and managed to develop the above system over time.  It came from comfort with our user-base, code quality (TDD as much as possible), relatively small app footprint, and traffic volume (release big features on monday morning for an audience of high school athletes, NOT on friday night =]).

I was nervous about daily deploys from the outset, for basic usability reasons:  people generally hate it when you keep moving their stuff every time they log in.  Fortunately, I had a small team, and managed all of the design/interaction work, so I folded features in gradually, made many of them optional until they were rock solid, and generally we got used to cranking stuff out every day.

On the PM/project team side of things, I cannot tell you how much of a relief it was working in that environment.  The immense weight of holding all of those expectations, requirements, iffy test results, and shaky sponsor buy-in - just drifts away when you release every day and continually prove the system is stable, usable and generating new traffic.

Across the entire span of the project, I believe there were two days (friday night to sunday morning) when a bug crept in behind our backs, blocking access.  Fixed that and went on without too much trouble.

I know it sounds cavalier, but managed properly, 3 week releases can be a god-send to your conscience, and your users' as well, since they get to see the system change very quickly after providing feedback.


5 May 2010 - 1:56am

Hi Jeff,

I'm a Scrum Master and PO for various teams and we have different iterations (= sprints) between the teams, if you have a small project with a short deadline, then you will even need to have sprints every week. The purpose of these sprints is to have production ready code after each sprint. If you put this logic on the UI issues in software than you first sprint will be to set the global framework, a second sprint will only focus on the UI regarding those features planned during that sprint.

Scrum has proven to be productive in this case and the customer knows what to expect after the sprint.


5 May 2010 - 1:57am

Very similar to Bryan, I also managed a web app from scratch to launch (twice) and progressed to shorter iterations and an agile methodology in a similar fashion. We had the added complexity of having client implementations that *could* exist in their own version (as uxrockabilly mentions) and hands down- the shorter 2-week iterations and 2-4 week public release cycles (since we wouldn't always go public every iteration) hands down yielded better results.

By better results I mean usability, and by usability, I mean that core interfaces weren't changing every 2 weeks. Instead, you're polishing features, making updates based on user feedback and engaging in free, real "usability testing". (Who's better to test than people using the system as they have to do get their job done, or enjoy their spare time? No, I'm not saying you shouldn't test everything yourselves first.)

By having shorter iterations, you're giving yourself the opportunity to continually refine your systems to meet your users needs now- and typically for a fraction of the cost. That's all assuming you've worked out a lean and mean management process around it, of course- and adhere to a interaction & style guide so your design & development team isn't moving buttons around on folks w/no notice.


5 May 2010 - 1:17pm
Jeff Wright

I manage the UX team for a relatively large and complex web app. Balancing a stable UI with the need for constant updates is a tricky one. Cadence is a big part of it.

Our Release cadence is roughly every ten weeks. A Release consists of four two-week Sprints, one Hardening week (just before deploy) and one Burn-in week (just after deploy). 

If we have bugs or small changes, we choose to deploy those on an as-needed bases, roughly every two weeks.

I think the pace of UI updates is entirely relative to the scale of those updates. In our case, our users use our application for their businesses, and the efficiency with which they can complete their tasks is important, so we're very reticent to change their workflow.

But we're less reticent to update text and graphics, for example, or areas of the app that are outside of the workflow (like a settings page or a welcome page, for example). I think you need to take it on a case by case basis, but an underlying Release schedule of several weeks is a helpful start.

And, though a stable UI is certainly a good goal, the truth is that we find users adapt pretty quickly and pretty favorably to good changes, no matter how frequent, and respond pretty negatively to bad changes, no matter how frequent. So if you have a genuine, tested improvement, it's less important how often you deploy. If you're launching untested changes that may hit or miss, then the stakes are higher, and change itself becomes much more of concern.

Syndicate content Get the feed