Agile and Custom Software
Starting a new custom software project is both exciting and daunting, both for the customer and the developer. I read a blog this week on Microsoft’s website that highlighted one of the most difficult parts: accurately estimating the scope of a project.
The author, Mitch Lacey, quotes Fred Brooks, ““It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data and certified chiefly by the hunches of the managers.”
In other words, at the beginning of a custom software project, your team of software consultants probably just doesn’t have a great idea of what the final product will look like yet. We use Agile methodologies like user stories to develop our best guess, but there is always an element of risk involved.
I’d like to take a few minutes to define for the business user a few techniques that can be used to lower this risk. Look at this as a window into how a software consultant works:
1. User stories: “One or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.”
2. Planning poker: “Consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development.”
3. Points: “Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work.”
4. Wall estimation: Also consensus based, this visual technique involves using a large wall to prioritize user stories. Small projects go to the left, big projects to the right. Important stories go up high, less important ones go low.
Moving from Uncertainty to Certainty
I really like the idea of combining poker planning and wall estimation, as well as doing a functional ‘slice’ in an application from start to finish as a way to flesh out architectural concerns and direction. There are a number of factors that are required to make poker planning work, however:
1) A thorough understanding of what the client wants, needs and expects, along with some understanding of the business drivers behind them.
2) Enough detail about a user story to properly weigh the size/effort involved, based on team velocity, experience, domain knowledge, etc.
3) An understanding of the process flow to facilitate prioritization. For example, you may have a story that is high in priority, but another story is needed as a pre-requisite therefore the other story gets prioritized higher than the first.
4) Full and open participation from the entire team, from developers, to business analysts to project managers to owners, with the freedom to express opinions, concerns, and objections, and to facilitate collaboration on the estimations being presented.
There are other factors that impact estimating effectiveness as well; I believe these are some of the higher impact factors. In a perfect world, you would get buy-in from the product owner/client to have a series of in-depth functional planning sessions to really flesh out as much of the scope of the application as feasible, then estimate on creating an application ‘slice’ that will take the path of a user, through the entire application to the end.
I like the statement that “Product backlog estimates are in points. Sprint backlog estimates are in hours.” Clients need to be able to budget the work being done, so it’s our job as the creator of custom software to provide them an estimate based on person-hours needed for a sprint.
For more on custom software development from the business user’s perspective, check out our director of consulting’s series of Agile and getting the most for your money.