Story Estimation

Increases accuracy by including all perspectives Builds understanding Creates shared commitment Story estimates includes build, code/peer review and functional testing (aka team QA tests) time

Story : A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved. A story should follow INVEST principles. Bug: A bug is a problem that occurs during the iteration and is tightly coupled to a user story that has not yet met its definition of done Spike/Enabler stories: Spike/Enabler Stories build the groundwork for future User Stories. These are meant to figure out answers to questions, promote learning, or reduce risk. There are generally four types of Enabler Stories: Infrastructure – Build development and testing frameworks that enable a faster and more efficient development process Architecture – Build the Architectural Runway, which enables smoother and faster development Exploration – Build understanding of what the customer needs to understand prospective Solutions and evaluate alternatives Compliance – Compliance enablers are used to schedule and manage specific compliance activities, including Verification and Validation (V&V), documentation and sign offs, and regulatory submissions and approvals.

A story point is a unit of measurement that estimates how much effort is required to complete a user story. For simplification, Story points are directly proportional to working hours; e.g. 1 story point = 6.4 hours

There are following key factors in the estimation process: Volume: how much is there? Complexity: how hard is it? Knowledge: what do we know? Risk/Uncertainty: what’s not known? These could include uncertainty or dependence on a third party. Repetition:How monotonous are the tasks? When a team member is familiar with certain tasks, the complexity and risk factors are reduced. All of these elements must combine for accurate story point estimation. A product owner will be involved in the story point estimation process, but they will not estimate Agile story points themselves — this is a team effort. The Agile team members will be the ones working on the user story, so they should estimate the required effort.

Estimate User stories, defect items (the defects which exists in team backlog) and tasks that are refined and ready Story estimates includes development, code/peer review and functional testing (aka team QA tests) time If a story has tasks, the total estimate of tasks can not be more than the story estimation Spike/Enablers should be time boxed DEV3/QA2 defects, Regression issues related to release candidates in Staging Note : A new story should be created if a new A/C is added to the story. Avoid modifying the estimates once it has been taken up in the iteration