March 18, 2008 - Estimating Lessons Learned - Agile Methods

One of the most pathetic looking sights on the highway is a man walking, head down, with a gas can. He represents the ultimate in poor estimating practices. It is bad enough that he ran out of fuel, but he was probably already late or he would have stopped to get gas. Having the embarrassment of trekking back to the car only adds to his dilemmas.

One of the misperceptions of Agile development is that the team continues to code until they “run out of gas” by hitting the target date.

Lesson 5 – Agile development requires estimation.

Although non-traditional methods differ in their techniques, they still rely on estimates to plan for and meet projected dead lines. We’ll look at three different types: Predictive Modeling, Time Boxing and Planning Poker.

In order to be effective, each of these estimating types requires a prioritized list of functionality and features that define the scope of the project. SCRUM estimates items on a Product Backlog. In the Rational Unified Process (RUP) Use Cases are identified and estimated at a high level (ex. 2 days for A and 5 days for B). XP uses Stories. The difference lies in the way the estimates are determined.

Predictive Modeling involves breaking the product into pieces and assigning relative work units to each one. For example, you may assign feature X 5 units and feature Y 10 units because Y is 2 times bigger or more complex than X. Initially you predict the duration for the first set of features and extrapolate the full project effort based on those numbers. Upon completion of the first set you have a better idea of how long it will take to complete the next, allowing you can refine your prediction. As each piece is completed you can more accurately estimate the remainder of the project.

Time Boxing is based on the concept of set periods of duration, anywhere from 1 to 6 weeks, for each release. Based on their size, complexity and dependencies, Use Cases (or features) are scheduled for specific releases throughout the project. At the end of each release the next set of Use Cases is re-evaluated to verify that they are the right ones and that they can still be completed in the timeframe. If a trend begins to appear showing that the team is consistently falling behind, the overall project schedule will require re-evaluated.

Planning Poker is a variation on the Wideband Delphi technique. In the 1970s Barry Boehm and John A. Farquhar expanded the US Armed Forces’ Delphi method to use multiple experts giving anonymous estimates for pieces of a project. Those estimates would be reviewed and the pieces with big discrepancies would be discussed in meeting and re-estimated.

As with every other aspect of development, Agile decided to speed up the process. In a Planning Poker session, team members are given cards with numbers on them, representing work effort (i.e. 3, 5, 10, 20 hours). Individual stories are reviewed and discussed by the team. Each member then selects a number from their deck that corresponds with their estimate. Only after everyone has picked a number do they show their estimates. If the numbers are close together, the value stands. When there is a large difference, additional discussion is held and another secret estimate is held.

Each of these estimating types has their strengths and weaknesses. Sometimes it is best to use a different technique for different parts of the project. The key will be how you explain and communicate the numbers to the project stakeholders. We’ll cover that next time.

February 11, 2008 – Did You Get What You Wanted?

It was the perfect gift. Our daughter’s CD / Cassette player stopped functioning in time to add it to the Christmas list. We found just the right one on line for about $60. Unfortunately by mid-January it quit. It didn’t start skipping or playing songs backward, it simply refused to turn on. We contacted the company and sent it back: $19 shipping and $6 handling fee. Within two weeks a new one arrived on our doorstep. Unfortunately it was the $30 model. She was willing to live with it until it ate the first cassette tape she tried to play. Did I mention it was a book on tape from the library and it was completely destroyed, resulting in a $10 fine? So by now I have invested $105 and own a tape hungry paperweight.

Do end-users ever feel that way? They’ve gone over budget and ended up with a product that vaguely resembles what they asked for but isn’t anything they could possibly use. How can we avoid disappointing them?

Involvement. There are two sides to involvement: (1) Getting committed users to participate and (2) Using them effectively. Sell the concept that their participation is essential to building a successful product. Let them know the effort involved and timeframes they will be needed. Get buy in from their management to dedicate a percentage of their time to the project.

In order to maximize their availability, plan in advance when and how you will use them. Invite them to a kickoff meeting and lay out the plan. The tendency is to only use them a bit up front for requirements and then again for User Acceptance Testing. Send your designer and even your lead developers to sit with the users for a couple hours at a time to see what they do. The more your team understand what they are creating the better they can design and build it. Every week (two at most) touch base with the end user. Re-confirm the schedule. Bounce the latest design off them. Keep them involved.

Bite sized chunks. Agile methods use the concept of frequent releases, as often as every two weeks. The concept is not new, only the implementation. If you are not in an agile environment, instead of workable code, aim to have something tangible every 2 – 6 weeks. It may be the draft requirements or prototype, but it should be something that confirms the project direction and gains the confidence of and buy in from the sponsor and key stakeholders.

Picture it. Graphic illustrations and mock ups help people visualize the direction of the product. Use Case Models was one of my recent blog entry topics. This is a great way to drill out requirements with minimal effort.

Get Touchy. Nothing peaks the interest of end users like a demo. Moving to a screen version that mimics the final product sparks the memory, too. All too often you begin to hear, "oh, yeah, we forgot to tell you about ." Try to keep your patience and remember that the goal is a usable product that meets their needs.

As a side note, make sure they understand what they are seeing. I used to program handheld inventory machines. We made the mistake of giving the sales people a PC based tool that allowed the client to view a mocked up version of the application. It was great for developing the requirements, but their assumption was that once it was on the computer screen we just had to download it to the scanner and ship it. I’m convinced some of the sales guys thought so, too.

Keep Control. In addition to controlling your patience, it is important to control the direction and duration of the project. Too many directional changes and the product will be outdated before it ever goes live. The best way to deal with this is by starting with a core functionality release and building on to it. When an enhancement or change is raised, define it, estimate its impact to the project and have the sponsor prioritize it. Agree on which release it should be part of and what gets bumped for it. Then get back to the current release.

Remain Flexible. It may sound contrary to keeping control, but flexibility is your ally. In the end it will be the users of the system that define if the resulting product is a success. Regularly verify the critical success factors of the project and align with them. When presenting the impact of a change, explain it in terms of the success factors. If the go-live date is vital, show how the request will impact the delivery. If functionality is key, reference the priority list and ask how the change fits into the bigger picture. Communicate the trade off and get their informed direction...in writing.

If all else fails, charge them a $6 handling fee and tell them to expect a box in about 2 weeks.