Story Points or Days, or Both?
People often argue whether to use story points or story hours (or days) in story estimation. Some people believe that we don't need to calculate story points and team velocity at all. Well, different teams may have different opinions, but nevertheless, most of the Agile projects do perform story estimation and consider it as one of the very useful tools in making projects on time and within budget.
Affinity Table for Story Estimation
In Visual Paradigm, we don't consider story estimation as a conflicting or negotiation process, but a team building process that makes task collaboration and workload clear and transparent to everyone in the team. The user story tool empowers team with Affinity Table for automating the story estimation process. Moreover, the visual Affinity Table supports real-time estimation with both story points and story hours at the same time. When you drag a story along the table, both the story point and hour will be shown simultaneously while the story is still moving around. Just drop the story in the grid where your team find the estimation is suitable.
How Affinity Table Calculate?
To understand how the story point and days are estimated automatically in the Affinity Table, we need to understand that the horizontal grids represent the work efforts, increases from the left to the right, and the complexity of the story development (such as new technology, new domain and etc.) increases from the top to the bottom.
As the maximum number of days for a user story to be developed should be no more than the length of the sprint (if not either the user story is to big that needed to be broken down, or the sprint is set too short which requires an extension), so the number of days of the bottom right grid should be also be equal to the length of the sprint. Based on this assumption, the story estimation can be calculated automatically.
Affinity of User Stories for Estimation
Estimation of a user story can never be 100 percent accurate and in fact no method can achieve this. To improve the accuracy of estimation, we start off by deciding the sprint length (say, two weeks, or 10 working days) and perform estimation on a few user stories that we feel most comfortable with in terms of estimation (say, 5 days and the certainty is medium). In this case, you will put the story in the middle vertically (certainty or risk level) and horizontally (work effort is equal to 5 day, or half of the sprint length, which is 10 days). You can then use it as a reference point in estimating the other user stories. Ask yourself whether this user story requires more effort than the referenced one, or less, and has more uncertainty or less). As you place some more user stories onto the Affinity Table you can compare among several user stories to determine whether the offsetting is logical or not, and then juggle them around to make them fair and that's it. The process is a little bit more an art than engineering. Do it and discuss in the team meeting rather than any confrontation. The accuracy will usually be improved as the team getting more mature.
Conducting Spike Investigation
According to Agile Dictionary the definition of Spike is:
"A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a "spike", which is some work whose purpose is to provide the answer or solution."
When estimating a user story we not only consider the development effort, but also take into considerations the risks and uncertainties involved. Quite often, a spike is created before the formal commencement of a sprint in managing the work required to be performed in order for some other user stories to be estimated fairly.
