In-depth software development----(iii) Playing Poker Game

(Notes from many years ago, migrated from Iteye.)

With unlimited brainstorming, role-playing, field observation and other needs-based access to a well-defined set of user stories, we need to assess the amount of work required for the entire development process as needed.

Here we use an interesting method----Playing Poker game, this is how it is done :

1. Put a well-defined, descriptive user story in the middle of the table
2. Each member participating in the estimate gives an estimated time to complete the development of the user story, with the time available to pre-define some commonly used time to write to the card, each of whom chooses a card of his own estimated time from his set of defined cards.
3. Put the estimate card face down on the table
4. Look at the film.
5. Dimensioning estimates to one-dimensional coordinates

The game itself is nothing special, it is mainly the same way to make the team's understanding of user story agreed, while the game in the process of further clarification of some unclear areas, to make a relatively accurate estimate.

If all the estimates are concentrated, the estimate for the user story is relatively accurate, and if the estimates are scattered, the estimate for this user story is inaccurate. either the team member's understanding of user story is biased or some assumptions have not been clarified. The first step is to agree on all members of the user story understanding. If the deviations cannot be further narrowed, then return to the customer and get more information about the user story until more accurate estimates are available, giving us confidence in our estimates. The estimate of user story is a commitment to the customer that we are able to deliver the functionality provided by user story within the estimated time.

Estimating the long user story is not a good user story. If a user story is estimated to be too long, say 30 days. Then the user story is too large and we need to break it down into a smaller number of user stories. This will make our estimates more accurate, not too big or too small. It is generally considered that the user story estimated to be greater than 15 days is more prone to miscalculation and therefore needs to be split. Adding all of the user story estimate development time is a relatively reasonable time for project development evaluation.

To take seriously every assumption we make when estimating, there is no hypothesis that the estimate is a good assumption, and theoretically every hypothesis should be clarified and eliminated from the client. This is because each hypothesis has the potential to be a variable in our development, giving us a fatal blow in the progress of the project (assuming that the error or hypothesis does not exist). Of course we cannot completely eliminate all assumptions, but at least we know that those assumptions have been clarified by our clients, and those assumptions require that we remain vigilant at all times. The assumptions that are not eliminated are the risks to our project.

Finally, it is entirely up to the project members to decide how to select Chengdu in the estimated value set. It also has to do with how confident the project members are about their own estimates.

In-depth software development----(iii) Playing Poker Game