-
Get a monthly update on best practices for delivering successful software.
Yes, by now, we all know that agile works and what an agile project feels like. It has a set of guidelines like individuals over processes, embrace change and working software. It also recommends process tools like scrum, iteration planning, retrospective. And for developers it is manifested as a
set of tools like pair-programming, continuous integration, TDD etc.
I have been on about 10 different agile projects in last 2 years. As a hands on developer, the one area that is of special interest to me is what constitutes an iteration, what deliverables and progress metrics it contains? Sure they all contain a set of stories to be delivered and a working software in the end. However, the risk for over promising and under delivering or vice-versa always exists.
The goal is to promise enough (not under) and deliver on it while still taking on a few unknown. Or put it another way, minimize risk somehow. A quick search on internet couldn't deliver a convincing set of traits that would do the same and I believe this area can use some refinement.
Here are a couple of things that, in my experience, constitutes a good mix of deliverables that minimizes risk and strives to deliver enough for a given iteration:
Deliverable user stories with varying estimates:
With experience, it is evident that delivering 5 stories worth 2 story-points (2+2+2+2+2=10) is very different from delivering 5+5=10. While 5 is usually broken into sub-stories, the crux here is to have a varying degree of complexity for stories in iteration. This allows for showing progress with long hanging fruits while dedicating more attention to relatively complex story. It also allows for shuffling items and pairs based to developers' schedule during iteration.
Targeted research items or spikes:
Yes, the obvious here is to not take on too many research tasks. Such tasks have no promised outcomes and are hard to estimate. Here at pathfinder, we make strive to make such tasks as concrete as possible in terms of what approaches are planned and how much time we decide to dedicate for all the effort needed. The story point for such task depend on how much %age of iteration (in terms of time) such task is going to cost. A research task that takes 1 full day in a 2 week iteration will be worth 2 story points if iteration has 10 story points (assuming 10 working days in iteration). In short, identify concrete approaches and time-box such stories. And each iteration should have not more than one or two such stories.
Bug-fix and Refactoring items:
These are good low-cost items, meaning relatively more predictable in outcome. Refactoring stories are relatively easier to estimate accurately and act as filler tasks that can be performed while your pair is unavailable. Or you are sick working from home. Or can be postponed until end of iteration if things seem slipping into next iteration. Having a healthy supply of refactoring stories is not a bad thing, they can be picked up if iteration seems to be under-filled since they don't require specifications or requirements and are targetted at improving quality of code.
Mid iteration demo and re-balancing:
Mid iteration demos are optional but we find those very helpful in showing on going progress. While scrums allow teams to be current about ongoing changes, mid-iteration demo is more for client update and re-balancing with clients. Showing progress with demo also helps with re-balancing of tasks with clients for the rest of the iteration.
Again the goal is to strive to be as concrete as possible in approach given the unknowns and minimize risk. What are some of the things in your experience that work?
Photo Credit: http://www.flickr.com/photos/27620885@N02/3018033419/
Related posts:
Topics: agile iteration
[...] Agile Ajax » What should a good iteration contain » Pathfinder Development (tags: agile iteration story xp scrum) [...]
Pingback by Mark’s Link Blog » links for 2009-07-16, Friday, July 17, 2009 @ 12:04 am
Nice tips.
I completely agree that teams need to limit the amount of “spikes” in an iteration – I’ve seen iterations with no output at all because of “spike abuse”.
Another thing you have to keep an eye on are bug fixing tasks. I’ve seen teams treating them as a separate backlog and that usually leads to either an infinite bug backlog (because of the usual lower priority assigned to them) or developers only working on bug fixes because they seem simpler to do, causing massive delay on the feature backlog.
Comment by Lucas Húngaro, Saturday, July 18, 2009 @ 4:36 am