All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers. For a Scrum overview, please see Agile Overview. This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.
At project initiation, the team will meet in order to determine the themes and goals of the project. In determining these themes, many factors will need to be considered. These themes will also need to be estimated and prioritised so that the development team knows what to build. These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done. The owner will determine the themes, but the developers will aid in this choice. Developers can help this decision by indicating the risk level or dependencies of each theme. These themes are often written on Index cards and should be considered at a high level of abstraction, such as:
- As a user, I require the ability to add new cars so that I can manage my growing stock.
- As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
- As a user, I want the software to record my high scores so that I can try and beat other scores.
Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.
The following is an adaptation of content I wrote to help a new agile team. It was meant to be a brief skim over the surface of estimation, rather than an exhaustive document. It generally sticks to the classical agile approach, but has some additional techniques that I have found useful. The information on which this is based is largely attributable to Mike Cohn, of Mountain Goat Software, perhaps my favourite technical author of all time and, for me, certainly one of the most readable. I would love to hear peoples opinions on estimation, feel free to drop me a line with any tools and techniques that you use.
It is very difficult to provide an off the cuff estimate for something unknown. We may hazard a guess or try and compare it to something else of similar or relative size. If asked to estimate the size of a mountain, it would be much easier to estimate it as double the size of another mountain than to specify a weight in kilograms. There is also significant scientific evidence to support the hypothesis than humans are much better at estimating relatively than absolutely.
Story points are way of estimating effort to complete a feature that decouples that tie to specific units of measurement, such as time. By estimating effort in relation to other estimates, we can derive a value for time. Because we have estimated relatively, our final value for time is likely to be more accurate.
A story point is a unit independent measurement of effort required to complete something. Features are measured in a number of story points.
A useful video by Mike Cohn discussing User Stories can be found here: http://www.youtube.com/watch?v=6q5-cVeNjCE.