TOPIC

AGILE PROCESSES: SCRUM

Presenter: Mehwish Rao

Business Analyst
 There are a number of ways to develop software, two of the most prominent
methods being waterfall and Agile
 Waterfall methodology is a sequential design process
 This means that as each of the eight stages (conception, initiation, analysis, design,
construction, testing, implementation, and maintenance) are completed, the
developers move on to the next step.
 But the main disadvantage of water fall methodology is Once a step has been
completed, developers can’t go back to a previous stage and make changes.
 Agile came about as a “solution” to the disadvantages of the waterfall
methodology.
 Able to move quickly
 Agile software development is a collection of software development methods in
which requirements and solutions evolve through collaboration between self-
organizing, cross-functional teams.
 In agile methodology developers start with a simple project design then start to
work on small modules
 The work on these modules is complete in weekly or monthly sprints
 Project priorities are estimated and tests are run
 Sprints allow for bugs to be discovered
 Faster/Earlier ROI

 Lower total cost

 Strong relationship with stakeholders

 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

 Person responsible for maximizing the return on investment

 Prioritize or re-prioritized task

 Leadership role

 Consider stakeholders interest

Development team includes members:

 Cross functional

 Programming skills

 Business analyst

 Domain experts

 Testing skills
Scrum master

 Facilitate the scrum process

 Help resolve impediments

 Enforces time boxes

 Leadership role

 Facilitator between product owner & scrum team

SCRUM FRAMEWORK
 The sprint planning meeting is attendant by the scrum master, product owner &
entire scrum team
 Product owner describes the highest priority features to the team
 The team ask enough questions related to user stories into the detailed task of the
sprint backlog
 There are two articrafts result from a sprint planning meeting

1. Product Backlog
2. Sprint Backlog
Product Backlog

 Everything we might ever do

 Customer centric features

 Prioritised by the product owner

 Does not contain task

 Contain backlog Item

Sprint Backlog

 Sprint backlog is a list of task recognized by the scrum team

 What we have agreed to do during the current sprint

 Sprint task represented how

 Usually in the form of user stories

 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.