In this assignment, we'll reference our User Stories for the online business start-up, and assign story points to them. Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty.

Readiness

• Please reference your 15 user stories related to the online business start up from earlier in this module.
• Assume your team's capacity is 32 story points.

Assignment:

1. Please identify a baseline user story - this might be the first one on your list or one that you feel is not too complex but not too easy in terms of effort. This will be used as a baseline to judge the effort of your remaining user stories. Be sure to indicate which user story is your baseline.
   • Assign an effort score/story points to your baseline story. To help with that, see this file: Story Points and this one: User Stories Effort Estimation Table
   • • Explain why you selected that particular user story as your baseline AND explain the user story points you assigned to it.
     • Using this story as your baseline, assign effort scores/story points to the remaining balance of user stories.
   • Once this is done (your user stories have an assigned story point value), please prioritize them, highest to lowest (although we should have had a sprint goal at this point, we don't, so please just prioritize in the order that you feel the work needs to be done).
   • Thinking back on the team's capacity of 32 story points, please determine what work can be assigned into the upcoming Sprint. In real life, this is what's done in the Sprint Planning meeting with you team.

Before uploading for credit, be sure you have (a) created a list with the user stories, (b) selected a baseline user story and explained why, (c) assigned the rest of the user stories a story point value referencing the attached effort estimation chart, (c) prioritized them and, (d) determined which work will be assigned into the upcoming Sprint but not exceeding the team's capacity.

Story Points File:

User Stories Effort Estimation Table File:

In Agile, teams will most often use estimates in a unit of measure called story points, as opposed to actual time estimates (such as hours or days). Story points are numerical values that follow a modified Fibonacci growth sequence, such as: 1, 2, 3, 5, 8, 13, 20, 40 and 100 . They represent levels of effort that can be more easily compared to one another due to the relative nature of the scale. For example, although it's hard to gauge how much a level five effort is different from a level six effort (a 20% increase), there's a clearer difference between a level five and a level eight (a 60\% effort increase). In the lower range of the scale, the absolute difference is small but the relative difference will still be high (for example a level two is double the effort of level one). It's this constantly large relative difference between one level of effort to the next that makes this system work. What Agile teams must agree on (or eventually learn through experience) is just what a single story point corresponds to in terms of actual work effort. Then, everything else can be measured in relation to that. Story points take time out of the discussion, because time is not always a reliable metric. If, for example, during a specific week every team member is busy with other corporate responsibilities, such as training or interviewing, then every task would need to be re-estimated with artificially high numbers of days (which would cloud the real effort behind them). With story points, the effort estimation always remains true. The actual delivery dates will vary with the team's availability, but this is understood from the start. Story Points - Takes less than 2 - 3 hours to complete this task. - It's mostly an isolated duty/request. - Not worth to be tracked in an user story. - VERY SMALL. Task can be completed in 8 hours or less (1 day or a bit more). - Very little perceived risk to other components, good clarity from customers on scope and acceptance. - No external dependencies. - SMALL. Task can be completed in 16 hours or less (around 2.5 days). - Defined risk to other components with little uncertainty from customers on scope and acceptance. - MEDIUM. Task can be completed in 32 hours or less (1 week, + /- 1 day). - Defined risk to other components, with some uncertainty from customers on scope and acceptance. - Some external dependencies. - BIG. Task can be completed in 60 hours or less (a full sprint). - Significant risk to other components, without clarity from customers on scope and acceptance. - Several external dependencies. - TOO BIG. Task can be completed in 80 hours or less (almost 3 weeks). NO stories this big. - Critical negative risk to other components, unknown details from customers on scope and acceptance. - Significant number of external dependencies. US needs to be splitted into smaller tasks