Professional Documents
Culture Documents
Low risk
Faster change
Quality work
Feedback
Visible progress
Teaming
A sense of done
Regularity
Realistic /Practical process
Adapt
Plan
Inspect
DO
• Product owner
• Development team
• Scrum master
Product Owner
Leadership role
Cross functional
Programming skills
Business analyst
Domain experts
Testing skills
Scrum master
Leadership role
1. Product Backlog
2. Sprint Backlog
Product Backlog
Most of the team also estimates how many hours to complete the task
A story point is a metric used in agile project management and development to
determine (or estimate) the difficulty of implementing a given story
Story points are an estimate of the time (effort) involved in doing something
Elements considered in assigning a story point include the complexity of the story
Story points are usually expressed according to a numerical range
such as an adaptation of a Fibonacci sequence, or according to a size range from X-
S (extra-small) to X-L (extra large).
It is a relative term and does not directly co relate to actual hours
story points have no relevance to actual hours, it makes it easy for scrum teams to
think abstract about the effort required to complete a story
For every team, story size could mean different things depending on what baseline
they chose.
IF two teams are given exactly the same stories one can say their velocity is 46 and
the other can say 14. Depends on what numbers they chose
If you really have to track time then don't use story points at all
A daily scrum meeting Is held in the morning
It helps set the contexts for the coming day’s work
These scrum meetings are strictly time-boxed to 15 minutes
During the daily scrum, each team member answers the following three questions:
1. What did you yesterday?
2. What will you do today?
3. Are there any impendent in your way?
Each sprint is necessary to deliver a potentially shippable product increment
At the end of each sprint, a sprint review meeting is held
This means that at the end of each sprint, the team has produced a coded, tested
and usable piece of software.
Typically this takes the form of a demo of the new features.
Participants in the sprint review typically include the product owner, the Scrum
team, the Scrum Master, management, customers and developers from other
projects.
The sprint retrospective is generally the last thing done in a sprint.
The complete team including both the Scrum Master and the product owner should
participate
You can schedule a scrum retrospective for up to an hour
each team member is questioned to identify specific things that the team should:
Start doing
Stop doing
Continue doing
A burn down chart is a graphical representation of work left to do against time
Burn-down charts are the most common sprint tracking mechanisms used by Agile
specialists
The first step is to have a task break in place
This is usually done during the sprint planning meeting.
Each task should have associated hours (ideally not more than 12, roughly two
days' work at six per day)which the team decides on during the planning meeting
Once the task breakdown is in place, the ideal burn-down chart is plotted
A burn-down chart can be maintained in a spreadsheet
Dates in the sprint are plotted on the X axis, while remaining efforts are plotted on
the Y axis.
Refer to the example below:
Sprint Duration – 2
weeks Team Size - 7
Hours/Day – 6
Total Capacity – 420
On Day 1 of the sprint, once the task breakdown is in place, the ideal burn-down
will be plotted as below
Each member picks up tasks from the task breakdown and works on them.
At the end of the day, they update effort remaining for the task, along with its status
Refer to the example below; the total estimated effort for Task 1.2 is 20 hours.
After spending three days ( 12 hours) on the task, if the developer believes that it
requires another six hours to complete, the "Effort Remaining" column should be
updated as 6 as shown in figure
Updating the burn-down chart:
For this example we are considering a team of 2 member with ideal working hours
of 5 hours per day
Working in a 10 days sprint
I have filled the estimates for each task
Now the cell E19 should be capturing the total estimated ideal work hours.
I have added the formula to sum the cell from E6:E18.
Ideal Burn Downs in terms of effort hours in each day
(Remaining burn down hours in day -1) - (total estimated burn down efforts for the
sprint/no of days in sprint)
In F15 and expanded that formula in the same row till Day 1 from day 10. As you can see
at the end of day 10 your burn down efforts become zero
Now let's define the formula for burn down efforts remaining on each day.
At the beginning of the sprint, actual efforts remaining is same the estimated
efforts remaining which in our case in 90 hours (F19=F20).
Now on each day you are going to fill in efforts remaining for each task.
Please note that you are going to fill how much efforts is remaining to complete the
task.
It's not how much effort you already put in.
So the actual efforts remaining on each day is going to be the sum of the efforts
remaining for the tasks.
It's possible that the remaining efforts required will go up
In the above example at Day2 the remaining efforts has gone up as the person
working on that uncovered a new issue.
• The Y axis depicts total hours in
the sprint (90 hours)
• The X axis depicts total days
• Ideal progress is shown in the
blue line which assumes all tasks
will be completed by the end of
sprint.
• Actual progress is shown in the
red line
The red line in the figure above shows the remaining effort on a daily basis.
If the red line is above the blue line, it means we are going at a slower pace and
may not be able to complete all the commitments.
If the red line is below the blue line, it shows that we are going at a better rate and
may be able to finish earlier.