Chris Spagnuolo’s EdgeHopper

Over the past two months, our development team has gone through a lot of changes…from joining a new company and setting up a new work environment to learning new technologies to serve our new clients.  In general, we were a desktop-based shop that focused on the ESRI desktop stack.  However, many of our new clients require web-based mapping applications.  As such, our team is currently climbing a very steep learning curve to work with a new set of technologies in a new environment.  More to the point, there are way more unknowns in what we’re currently doing than we’ve ever dealt with in the past.

One of the issues this has raised for us is how valid our current user story estimates are.  Right now, everything seems more complex because we are researching just about everything we’re doing.  Will the story points we assign to a user story today be valid in 6 months when our tasks become commonplace?  Can we use our current velocity based on our learning curve to provide estimates for new work? We have lots of questions running through our heads right now and we’re coming to grips with some of the answers.

Earlier today I was speaking with Ryan Martens, the CTO and Founder of Rally Software Development, and I asked him what he would do in this situation.  Ryan presented two solutions, both of which I think are very useful and effective for resolving our estimating issues.

The 3-Month Sliding Window Approach

One way to address the learning curve is to use a 3-month sliding window approach.  In this approach, recent history is more important than long-term history.  Go ahead and give the user stories the story points you think they deserve based on your current level of knowledge.  But, as you go forward use the past 3-month’s worth of estimates to derive your team’s velocity.  Keep the 3-months of estimates and velocities sliding forward so that as you move forward and learn more, your estimates and velocity are based on your most recent metrics, not on those gathered during your earlier stages in the learning curve.  The further along in your technology transition you progress, the more stable your estimates will become.  Once your transition is complete, your estimates and velocity should be far more valid than they were at the beginning of your transition.

Factor Out the Learning Curve

Another way to deal with the learning curve is to just factor it out of the equation.  Split the new complex user stories into two pieces: the research component and the actual development component.  Add research spikes to your iterations to learn how to do whatever it is you’re getting up to speed on.  Once you figure out how to do it, then estimate the user story in another iteration.  The isolated user story estimate should be closer to a valid value than if you considered it together with your research task.

---

© Copyright 2007, ChrisSpagnuolo.com GeoScrum! by Chris Spagnuolo is licensed under a Creative Commons Attribution 3.0 United States License.