The tickets are essentially arrange as a grouping of tasks into manageable parts to give the developer all the information required to complete the work while helping determine the progress of work as it is completed.
The epic is the top level task item that defines a shippable feature or main theme to a group of work. This ticket should define from a top level, what the feature is intended to do, how it will look for the user and give enough information that further user journey stories can be written from it.
This will also include a high level relative estimate covering time and complexity as well as a relative business value, the combination of these two values determine the priority of the product backlog and therefore the delivery.
The stories are the testable journeys from the users perspective. They include the full user stories, acceptance criteria and designs and are duplicated for each platform.
A story is likely to have multiple 'user stories' which describe variations in either the user, the act or the benefit, however if there are many variations then consider splitting into different stories. Each different user journey path should be a new story, for example one register via Facebook, another for register via Google, both are under the register via social epic.
These are non-testable work, usually the items created by a developer that make the story work. Majority of the points will be in accounted for in tasks since most the time and complexity is spent delivering them.
Sub-tasks are not tracked but simple list of tasks that need to be done to deliver the task, particular when they are done by different resources.
If the epic is currently being worked on, in the current sprint, then a bug will be raised as a sub-task to the main story. The points in the story account for testing and resolving bugs.
If the fault is for an epic has been completed in a previous sprint, then a task is raised as type 'Bug'. Unless it is flagged as "Highest", then the bug will appear in the backlog, they are put in priority order by the Product Owner and then estimated by the developers in that order.
Bugs are then selected along with new features for a sprint.
Epic points are not used in the burndown charts, they are simply for sprint planning with high level estimates.
The Story's points account for mostly the testing and QA time and bug fixing, where as the Task's points account for the development time.
This way as the development tasks are completed, it will reflect in the burndown chart to give us a true indication of the progress. Of course the feature is not available until the story is complete but the purpose of the burndown chart is to display progress rather than feature availability.
Velocity = Points / Time
Velocity is the average number of points we have closed across multiple sprints, at least three to get an average but the more sprints averaged, the more accurate our velocity is.
Changes to a team can affect velocity and it may be adjusted accordingly, for example if a developer is on leave for one sprint, the velocity will be reduced to affect his or her percentage of work.
Points are not relative to time, they are relative to each other, however, time can be predicted once we have relative values.
If we have a previously completed task which had a value of 5 points, and our new task we determine to be double the time or complexity, we would apply 10 points to that task.
Once the points are estimated for the stories and tasks from the epic, the epic's points value can then be updated to a more accurate number.
Since the velocity is also a variable, it's adjustment will affect time.
Time = (points / velocity) * weeks per sprint
Example: If we have a velocity of 40 points per sprint, we have a release defined with epics totalling 110 points, it will take 3 sprints to deliver this release. 110 / 40 = 2.75 sprints, therefore with two week sprints 3 (sprints) x 2 (weeks) = 6 weeks.
The three values that are defined in scrum, velocity, time and points (features), can all be variables, depending on who you ask of course and the stakeholders will define which are constants and which are variables. The usual approach is to define the time and the points, being the number of features stakeholders want by a certain date. The obvious variable then is velocity, resource.
However adjusting and changing your team to alter your velocity introduces the most risk, adjusting points is far easier followed by adjusting time by moving your release dates remembering that you can have multiple releases.
Time: time can be adjusted by defining releases, later releases equals more time.
Points: total points be can adjusted by reducing features to the backlog for later releases.
Velocity: adding resource can increase velocity, bearing in mind that additional resource will have a lag effect on velocity while new resource ramps up.
In initial project epic planning, if the time and points are a constant, that is they can not be moved, then adding velocity can sometimes be the only option to reach the required release feature set. However, this is a negative exponential distribution of points. Tripling your developers doesn't automatically triple your velocity.
So to determine your resource count required, you need to work out your required velocity and current velocity per resource.
Resource required = (total points / sprints available) / (current velocity / current resource)
Total points of 110 with 2 sprints available is 55 points per sprint, which is the velocity required.
Current velocity is 40, not enough obviously but current resource is 2, therefore velocity per resource is 20.
55 / 20 = 2.75 which means we need 2.75 of required resource.
This may seem like we're wasting the 0.25 but in reality, the new resource is more than likely going to be less than your current devs at their full speed of 20. While I can come up with a formula to better calculate new resource lag values, any new resource is relatively an unknown and simply rounding up is as accurate as you can assume.
Now that we have a velocity and we have a selection of epics with estimates, we select the epics that will fit into a sprint. For example if we have a velocity of 40 and we have three epics with values of 20, 10 and 8 points, they will all fit into a sprint with 2 points to spare.
If the estimates are greater than actual and the work is completed early, we can bring up tasks from the backlog. Alternatively if our estimates have fallen short of the actual work required, luckily we had two extra points up our sleeve otherwise that time may have been used for R&D.
Sprint estimate values and velocities do not need to take into account 'regular' tasks such as planning sessions, stand-ups, retrospectives, coffee runs etc, because these tasks are included in every sprint and therefore make the velocity consistent.
|Epic||Register via social|
|Story||Register via Facebook||Register via Google||Register via Email|
|Task||Setup Gigya SSO||Create SSO pages||Connect Facebook app||Connect Google app||Email Forms||Setup Database|
|Subtask||Designs||Icon for Facebook||Icon for Google||Designs|
|Level||Description||Example Points||Burn Down Points|
|Epic||Total points for a feature compared to other features||100|
|Story||Points to cover user and regression testing||5||2||
+ 10 = 17
|Task||Points for each technical task to achieve the story||1||5||2||1||1|
|Subtask||Points are not tracked in sub-tasks|
|Bug||Points cover resolution of issue||2|