25 October, 2006 / Are One-week Iterations Possible in Web Development?

2 comments

Recently I’ve discovered Steve Eichert’s post about one-week iterations in theirs project. Honestly, as I read through, I felt something wrong about their process, at least it was my perception of provided information. I really wonder about QA. They fix bugs 0.5 day, I can imagine that it is possible, but how about testing and verification?

We are doing two-week iterations (10 working days) and typical iteration looks like this.

1 day. First day is Tuesday. In Tuesday development actually started. Iteration plan created on Monday, but this is not considered as a part of iteration in general (see 10 day for more details).

2-6 days (from Wednesday till Tuesday). Development of new user stories. In general we do not test unfinished features, since there is a big chance to get “Hmm, I don’t find that checkbox” bugs. So feature is not tested till completion, just some smoke testing may be done.

7 day (Wednesday). Pure testing. In this day whole team run acceptance tests (if one or two developers still need 1 day to complete user story, they may continue with development, but this is resolved on morning daily meeting). Usually full day of testing is enough to assert quality and collect about 20-30 bugs.

8-9 days (Thursday and Friday). Testing, bug fixing and verification, just QA activities.

10 day. Last day is Monday. During the first half of the day we are fixing and verifying bugs, releasing new version, making announcement and updating online demo. Second half of the day (usually 3 hours) dedicated to next iteration planning. We discuss priorities, select and re-estimate user stories, make initial assignments.

So we dedicate 3-3.5 days from each iteration to QA activities (about 30-35%) and 5% to iteration planning. If we’ll run 1 week iteration with the same proportions, activites distribution will be:

  • Planning – 0.25d
  • Development – 3d
  • QA – 1.75d

So on average developer will have no more than 3 days to complete user story. In most cases it is OK, but you should be very careful with user stories and split them on smaller whenever possible. And I should say that such splitting is not ALWAYS a good thing. We have user stories that just can’t be smaller. One latest example is Bug Submission utility. It can capture screenshots and post bugs into TargetProcess without web-browser. It is fairly large user story (maybe even theme) estimated in 20 points. It was developed during 2 two-week iterations and actually was artificially splitted on 3 stories:

  1. create screen capturing utility (8 points)
  2. send bug functionality (8 points)
  3. beautiful UI + installer (5 points)

But in general customers don’t need the tool without any of the smaller user stories above, so it will take four one-week iterations to implement it and it requires even higher granularity. I don’t think it is a good way to go in this case.

Maybe our agility is not as high as demanded by one-week iteration, but I don’t think they can work better than 2 weeks iterations in almost any web project with 4+ developers.

What Can Be Improved?

In fact acceptance testing is a weak side of our process since we don’t have automated acceptance tests. Everything fine with unit tests (we already have about 500 fancy green tests :), but acceptance tests are harder to automate and support. We’ve tried web tests from MS VS Team Suite, but they don’t work with AJAX (really funny, Microsoft developed Atlas, but did not provide compatibility). Currently we are looking into Selenium and it seems very promising tool (test recorder, AJAX compatible, continuous integration support).

The second thing in our road-map is Continuous integration. We are working together in one room and so far broken builds are not a big problem, since problems discovered early and fix within minutes, but with automated acceptance tests continuous integration will provide even more value, so we are going to setup Cruise Control and have several daily builds with acceptance tests results.

Then we are going to integrate TargetProcess with both CC and Selenium and have real-time stats about project progress. This will be really cool.

2 Comments:

At October 25, 2006 2:46 PM, Anonymous Steve said...

Thanks for the link :)

When I mentioned we usually have .5 days to fix bugs that is strict bug fixing without any other development work going on. Throughout the week our QA group does testing and lets us know of bugs that they've found. Often times the bugs are fixed (or at least thought about) before Friday rolls around. We usually try and keep Fridays light on the development side so we can spend the time necessary to cleanup any bugs that have cropped up.

It isn't always easy, and we have thought about moving to 2 week iterations. However, I think any problems that we have are due to shoving too much stuff into too small of a timeframe. Perhaps sometime soon we'll give 2 week iterations a try? :)

 
At February 17, 2007 11:54 PM, Blogger kelly.waters said...

I found your post really interesting. We're implementing agile development right now and going through the same debate about how long our sprint should be. 30 days recommended by scrum just seems too long to create any real urgency, especially on a web development where deployment is centrally controlled. On the other hand, 1 week does seem very quick to get anything meaningful done. We're starting out with 2 week sprints, so we'll see how that goes for us.

http://kellywaters.blogspot.com

 

Post a Comment

Links to this post:

Create a Link

<< Home

 

We are developing TargetProcess agile project management software and blogging about our progress.

Subscribe to the RSS feed
Stay tuned by having the latest updates via RSS
Follow TargetProcess on Twitter
Get in touch with our team

Try TargetProcess
TargetProcess quick tour