As I think back to why the Transition Assist project took as long as it did, 2 primary reasons come to mind. The first reason is not so interesting – team member allocation was not as high as it should have been.

The more interesting reason is that the core feature of the website – a health plan comparison tool – required a very complex user interface. This UI included the ability to search, compare and save complex and detailed health plan information, which required many rounds of refinement.

As a lesson learned, features requiring a complex UI should be identified up-front with a plan for continual refinement (ideally including user testing) built into the project plan. Of course, continual refinement will burn through a fair amount of hours, which may end up detracting other tasks. All of this should be considered when identifying the scope of each iteration.

I think we did a good job of identifying the complexity of the plan comparison feature up front, but I also think we under-estimated the amount of refinement that would need to occur throughout the project.

Despite this lesson, I do think the project was a success and I was amazed by how much functionality we actually delivered in such a short period of time. Once again, the Ruby on Rails platform proved to be an excellent choice.

Sounds like the Agile process really worked in your favor even in the short duration. My own experience with Agile comes from reading about it and practicing it only with a small team (4 person team). Some have said that Agile doesn’t work best in such a small team.

Nonetheless, I took note of the important parts of XP and Scrum and made my own process called SPIT. Note that I was in a start-up environment where prototyping and time to market were crucial elements of success.

S = Simple. Quality of code is important but in a start-up environment, simple is more important. If you don’t need layers of abstraction, just keep it simple.

P = Priorities. I mainly prioritized the top 10 things to be done. Item #11 and beyond goes on to version 2.

I = Iterative. We released new functionality every two weeks. We released bug fixes every week.

T = Tested. Testing, testing….I can say enough about testing. We didn’t have a QA team but even user acceptance testing in terms of core functionality was key.

I came up with the acronym so we can say “Let’s SPIT out products quickly”.

My 2 cents.

Ivan

Good to hear from you man!

So, planning poker. The idea behind planning poker is that an aggregate estimate from all team members is more likely to be accurate than from a single member. Here’s what you need to play:

1. A project
2. A team, ideally multidisciplinary and all deeply involved
3. A collection of user stories
4. A deck of estimate voting cards
5. A table and some comfy chairs

The estimate voting card “hand” consists of note cards with the following values written on them:

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?

Each player of the game gets a hand of these cards.

To play the game, pick one of your user stories and read it out loud. The players should discuss the stories, clarifying it if needed. Once the players agree that they have an understanding of the story, it’s time to play the hand. Each player has to minutes to select an estimate value from their hand and play it face down on the table. After everyone has played a card, they’re all turned face up and compared.

An average estimate value is computed from the played values. For example, is a game with three players, the estimate might be:

Charlie: 5
Stella: 5
David: 1/2

The team estimate here is 3.5 hours (at least is some versions of the game. Some folks don’t uses averages) . At this point the team discusses the estimate again and can either choose to accept the current estimate, manually adjust the estimate and accept the new value, or play another hand with the same story. How do they decide what to do?

First off, there are a couple of things to watch for in a planning game. One is wide variances in estimation, either high or low. For example, in the example above, David’s estimate was considerably lower than his fellow players. This is a sign that something’s not right and needs further discussion. David could just be a really poor estimator, or perhaps he has information that leads him to believe the task is far simpler than the others has assumed. In any case, such wide divergence warrants discussion and probably another round of estimation so see if the players can get closer to a flat consensus.

Another thing is to watch for is having too much granularity in the estimate deck. The levels I’ve described above are those used by the online planning game at http://planningpoker.com. I really like this site, since it allow remote players to use the planning game. However, I think that there are too many cards in the hand. I like the suggestions in this InfoQ article: http://www.infoq.com/articles/agile-estimation-techniques. The powers-of-two suggestion and capping out at 8 hours is good.

The cap is another important item. Any user story that takes more than 8 hours in an estimate is probably not specific enough to implement. In other words, it needs to be decomposed or re-written.

There’s a lot of information on planning games in the agile development literature. They’re a great way to generate estimates that have some chance in heck of being more-or-less correct.

What worked well:
The client was open to receiving informal documentation and deliverables (e.g. napkin sketches)
Transparency throughout the project, which is hard for designers to do – let you client into your studio to see a work-in-progress

Bottom line, we were able to produce as much as humanly possible in a limited amount of time. Longer iteration cycles will allow for additional design and multiple rounds of reviews/iterations (and not require homepage comps to be produced in a weekend).

Lastly, as George mentioned and I feel is necessary to reiterate, the team was very happy at the end of this project!