Stories also called “user stories,” are short requirements or requests written from the perspective of an end user.
Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
Initiatives are collections of epics that drive toward a common goal.
Themes are large focus areas that span the organization.
User Story Template
Acceptance criteria:
Acceptance criteria is a detail description of system or feature put forward by the product owner, it's a criterion against which the user story should be validated and tested
Story Point:
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.
In most cases a story point uses one of the following scales for sizing:
• 1,2,4,8,16
• X-Small, Small, Medium, Large, Extra-Large
• Fibonacci sequence: 1,2,3,5,8,13,21
However, it is tough to identify a story from the scales assigned to them. In order to do that each team would have to find a baseline story. It does not necessarily to be the smallest one, but the one that everyone within the team can resonate with. Once determined, sizing of all the user stories should be initiated by comparing them against the baseline.
While estimating story points, we assign a point value to each story. Relative values are more important than the raw values. A story that is assigned 2 story points should be twice as much as a story that is assigned 1 story point. It should also be two-thirds of a story that is estimated 3 story points.
Now let us understand sizing in detail:
First, let us start with the importance of sizing.
Sizing is beneficial as it:
- Gives us an overview of the scope of work
- Uses multiple perspectives to determine the size of work
- Clears out that we can’t be exact
- Rectifies false assumptions
Sizing is done ideally by the Agile delivery team (normally scrum team) For eg. consider a task of traveling from Delhi to Mumbai. The duration of the travel depends on the mode of transport (Think mode of transport as the technology with Flight taking 2 hours and Car 22 hours). If you choose to travel by the road, your driver’s route knowledge (domain knowledge) is required to reach on time. Duration is dependent on multiple factors, but the distance is approx 1400 Kms which is constant and doesn’t change. Now, replace the distance with size. Size is easy to estimate, but not the duration.
Sizing is done considering:
• The amount of work to do
• The complexity of the work
• Risk or uncertainty in doing the work
• Time / Duration
An estimate of effort/duration isn’t possible in Agile, unlike traditional projects. This is because the duration is dependent upon:
- Technology / Tools
- Domain Knowledge
- Skill-set (technical expertise) of developers doing the work
Outlined below is the relative sizing process:
1. List all the stories to be sized
2. Put them in order from smallest to largest
- Take the first user story
- Then take the second user story
- Decide which is bigger and put the bigger one above
- Then take the next one and decide where it fits relatively to the other two
- Then take the next one and do the same
- Repeat the process until all the stories are now in the list (in a sequence from smallest to largest)
3. Size the stories
- Start from the bottom and give that story a number 2 story points. Giving ‘2’ provides you the room to give a smaller story ‘1’ if discovered at a later stage.
- Look at the next story and decide how big is that story as compared to the first one
- Continue until you have a size on each story
- Use these set of numbers (influenced by Fibonacci) while sizing: 1, 2, 3, 5, 8, 13, 21
Velocity:
It is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum.
Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories divided by the number of fully completed Sprints.
Ideal Day:
A unit for estimating the size of product backlog items based on how long an item would take to complete if it were the only work being performed, there were no interruptions, and all resources necessary to complete the work were immediately available.
Ideal hour:
A unit for estimating the size of the design, build, integrate, and test work, represented as sprint backlog tasks. Often referred to as an effort-hour, person-hour, or man-hour.
Burndown Chart:
A burndown chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.
Comments
Post a Comment