Scrum helps people and teams deliver value incrementally in a collaborative way.

As
an agile framework, Scrum provides just enough structure for people and teams to
integrate into how they work, while adding the right practices to optimize for their specific
needs. Scrum is where the team comes together to move the product forward.

What is Agile framework?

Agile is a time boxed, iterative approach to software delivery that builds software incrementally from
the start of the project, instead of trying to deliver it all at once at the end.

Agile is governed by the four values and twelve principles as provided in the Manifesto for Agile
software development

The four values are listed below:

• Individual and Interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Twelve principles of the manifesto for Agile software development

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation.
6. Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
Scrum Cycle is the iteration in Scrum popularly referred to as
‘Sprint’. A sprint consists of Plan-Produce-Inspect-Adapt.
Application development, is achieved by sprints in a sequence
with no gaps in between them.

1. Plan - The work to be done(how much and what)

during the sprint and the deliverable to be given to
the customer at the end of the sprint are decided by
the team. Planning is done for the sprint at hand
2. Produce – Whatever has been planned is
implemented by the development team
3. Inspect – At the end of the sprint, the customer
along with the stakeholders verify the product to see
if it meets the requirements as per agreed
conditions called definition of done (more on this
later)
4. Adapt – The team retrospects on what went well in the current sprint, what can continue and
what can be done better in the next sprint. Improvements in the process are discussed here.
Doing this would help them to continuously improve the way of working across sprints

Sprint – The timeboxed iteration in which deliverables are produced by the development team.
Sprints happen in a sequence.

Cross functional – Refers to the diversity of skill sets present in a development team, ranging from
developers, architects, testers, analysts etc.

Definition of Done ( DoD) – This is a generic checklist of conditions agreed upon between the
customer and teams on what can be considered done.

Roles (People who are part of a sprint)

1. Product Owner
2. Scrum Master
3. Development Team
Ceremonies / Events (Meetings conducted in a sprint)
1. Sprint Planning Meeting
2. Daily Scrum Meeting
3. Sprint Review
4. Sprint Retrospection
5. Product Backlog Refinement

Artifacts (Deliverables produced)

1. Product Backlog - Pending list of items to be developed
2. Sprint Backlog - List of tasks planned for the current sprint with their effort estimate
3. Increment - Working version of the software produced in the sprint

Vision statement:

User stories- tend to bridge the gap between business language and technical language.
The INVEST principles coined by Bill Wake can be used for writing good user stories and reviewing
them. User stories are written and groomed throughout the project.
What is prioritization?
Prioritization helps Product owners
identify what is valuable at that point
in time so that value driven
development can happen. This is
inline with the principle “Simplicity
the art of maximizing the amount of
work not done is essential”

• Methods are based on

o Feature urgency(MoSCoW)
o Business Value
o Risk
o Dependency

Steps in Release Planning

Release Planning comprises of the following steps that are explained in detail subsequently.
What are story points?
Story Point is a size associated with a story and it is NOT the effort in days. It is influenced by the
amount of work, complexity, risk and uncertainty but not very precisely. Story points are provided
using relative estimation technique.

sprint duration?
The sprint duration has to be apt to deliver increments as expected by the customer. In general, the
sprint duration is usually fixed between 2 to 4 weeks.

The Steps Involved & Practical tips

• Product owner or representative will read out a story to the entire team
• Product owner will clarify questions if any
• In case of consensus, the story point is recorded against the story
• If no consensus, the high and low estimators provide explanation and polling is conducted
again
• Continue this process until consensus is reached, up to maximum of three (3) iterations
• If no consensus, Scrum master will decide the value
• Offshore teams also should be involved in this activity

What is velocity?
The number of story points that the team can complete in one sprint is called velocity. Velocity of a
team represents the speed at which teams are moving forward with agility. It is an important metric
which is measured in Agile software development.

Release date?
Step 1: Divide the total story points for the product backlog by the velocity to get the number of
sprints
Step 2:Multiply the number of sprints by the sprint duration (in weeks)
Step 3:Add Buffer-
• Towards Uncertainty (for example: 15%)
• For Improvement and rework (for example: 10%)
Step 4:One Pre-release sprint (to go from potentially shippable to actually “shipped”)

The tentative release date is calculated as follows-

Total Story Points (TSP) = 360

Number of sprints required = TSP / Velocity = 360/60 = 6 Sprints
25% Buffer = 2 Sprints
1 Pre-release Sprint = 1 Sprint
Total Number of Weeks = 9 Sprints X 2 Weeks each = 18 Weeks
Tentative Release Date: 18 weeks from 02-Apr-2017 = 04 Jul 2017 (Approximate)

The release Burndown Chart is useful to the product owner and provides an idea of the
progress

How is the burndown chart drawn?

On the X-axis, the number of sprints required are plotted. On the Y-axis, the story points to be burnt
down are plotted. A line is drawn connecting the total story points planned on the Y-axis to the last
sprint in the X-axis which represents the ideal line
 • Agreed deadline / release date cannot be changed and hence de-scoping of requirements
can be done. If requirements in the form of user stories are prioritized properly (say
MoSCoW), the stories that will be de-scoped will be those which are "could have" (C) or "won’t
have"(W) items.

• The other option for the product owner is to extend the release date to ensure the completion
of all the items.

Team enablement
This step is important because teams need to understand the philosophy of Scrum. This will also
remove unnecessary apprehensions (my job role will go away, my work will get exposed etc..) that
the might have while moving to scrum.

Teams can take up internal training programs and also certifications.

Base architecture and design

Teams may need to spend time on base architecture and design before proceeding to sprint. If it is
very intensive, a couple of sprints may be spent on architecture and design also. However "Water
scrumming" / "Scrum fall" is to be avoided. ie., creating a mini water fall with in the scrum (few
sprints on requirements, then few sprints on design etc..)

How is this done?

Teams can use standard design practices (design patterns, emergent design etc.) to arrive at the
base architecture and design. The design made however needs to lend itself to change.

The tooling and infra required (testing environments, communication etc..) need to be decided here.
This becomes even more important when the teams are distributed.

Quick Recap
• Sprint 0 and Initiation phase does the just enough planning required for the project
• This phase can span about 2-3 weeks and it involves the following-
o Communication of vision statement and team onboarding
o User Story writing
 o Prioritization
o Story Point estimation
o Computing the sprint duration, velocity and release date
o Team enablement
o Base Architecture, design and infrastructure set up

We have completed the release planning for the Project. Now let us see how to execute the
sprints (1 to N).

Sprint planning?
It involves micro level planning for the user stories that would be developed during the sprint based on the
prioritized order. Planning in small pieces for what is in sight contributes to value driven development.

The sprint planning is done during every sprint and is an integral part of it. The Scrum master
facilitates the planning with the entire development team. The Product owner needs to be available
to clarify questions on user stories picked for that sprint.

The Scrum guideline says, half a day for a two-week sprint. This can be pro-rated as per sprint
duration.

How is sprint planning done?

Calculate capacity of the following team in hours, for the upcoming 2 week sprint:

• The Company has a 5 day week and 8 working hours per day
• The team has 8 members
• 1 member is on vacation for a week
• 2 team members are in training for 2.5 days each
• 1 team member is being shared by another project so he is available for only 50% of the time
• 25% of the day time to respond to emails and meetings etc for all the team members
Produces Working Software
This represents the produce phase of the sprint. The development team need to execute the tasks
committed in the sprint backlog to produce working increments of software.

The development team produces the working software during the sprint as per the capacity
calculated. The Scrum master facilitates this activity by ensuring impediments are removed and the
user story clarifications are resolved with Product owner.

This spans as per the actual capacity calculated, typically 7.5-8 days for a two week sprint

How is working software produced?

The development team uses a visual board to keep progress of the tasks. The initial visual board is
shown below. If it is a co-located team, a white board with yellow sticky notes can be used to
represent the visual board and the tasks respectively. If teams are distributed, ALM tools like Jira
(from Atlassian) provide a similar interface. Other tools include Rally , Mingle , TFS etc.

• The sprint burn down chart is updated on a daily basis

• HLD and DLD documents do not represent working increments
Daily scrum meeting
The development teams, Scrum master and the Product owner need to be aware about the progress
of the team and impediments (if any). A daily scrum meeting (aka daily standup meeting) brings the
team together and each member updates the progress and the issues impeding it. This is one of
the four ceremonies of the sprint.

The entire development team participates in the daily standup which happens every day for 15
minutes. It is facilitated by the Scrum master.

Each team member says three things –

1. What did I do yesterday?

2. What will I do today?
3. What is blocking me?

Product backlog grooming?

Product Backlog Grooming helps in fine tuning the user stories for the upcoming sprint and also
incorporate changes to priorities of user stories. This is one of the four ceremonies of the sprint.

If development teams start on "what" stories to pick up during sprint planning, they would not be
able to complete the same in the stipulated period. Hence the need to groom stories one sprint
ahead. This is also called sprinting ahead sessions / product backlog grooming.

This is done for about half a day for a two-week sprint and is done every sprint. The entire
development team participates and is facilitated by the Scrum master. The PO needs to be available
for clarification of queries.

The development team grooms i.e. writes acceptance criteria or understands the stories better.
Three things may happen in the grooming –

1. PO can revisit the priorities of the user stories, teams may revisit estimates for the user
stories
2. PO can add new user stories, however the timelines may have to be revisited
3. Understanding of user stories for next sprint

Review
During review, the Product owner inspects the increment based on DOD and acceptance criteria.
During retrospection, the team looks at ways of improving the process. This is the fourth ceremony
carried out in a sprint. In order to produce and deliver valuable software frequently to customers,
early feedback by the product owner is essential.

This is done towards the end of the sprint for half a day. The PO, stakeholders participate the review.
The development team demonstrates the working increment produced

How is the review done?

1. The PO reviews the working increment against the acceptance criteria and definition of done.
2. The PO declares “doneness” of items and provides feedback on what is not done
 3. The PO might provide changes. They are measured and then a call is taken to add it as a new
item to the product backlog
4. The stakeholders review the working increment and provide feedback to PO

Retrospection
In order to bring about improvements and innovations in the working of the team and the process,
retrospection is done

This is facilitated by the scrum master and the development team participates

Each team member mentions the following –

1. What to start doing from next sprint?

2. What to stop doing from next sprint?
3. What to continue doing?

What are the principles?

Kent Beck has defined the Simple Design principles which help in maintenance of code and ensure
that it integrates well and lends itself to changes.

Let us revisit the principles once again. Every time the code is written the increment should:

• pass all the tests

• reveal the intention
• not contain duplication
• have the fewest of the elements

What is refactoring?
The process of changing a software system in such a way that it does not alter the external behavior
of the code, yet improves its internal structure

Modern day IDE's have features that help programmers to refactor code. There are many refactoring
patterns that need to be understood by developers and with the help of tools, use it in code.

Practical tips
• Buffer time for refactoring every sprint
• Do not refactor very close to release
• You may refactor code that is being newly developed rather than already existing code
(legacy code)
 • Sensitize customers on the need for time to be allocated for refactoring

What is TDD?
Is a software engineering approach that involves short development iterations consists of writing
failing test case(s) first covering a new functionality and then implementing the necessary code to
pass the tests and finally refactor the code without changing external behavior.

XUnit frameworks help in writing automated unit tests. Thus TDD includes both test automation and
refactoring.

What is Continuous Integration (CI) ?

A software development practice that requires members of the team to integrate their work
frequently. Integration is done at least daily. It leads to multiple integrations each day.

The developers(ex. Dev1 and 2 shown in figure) commit code to a source code repository. Post this
the build phase activities of static code analysis, unit testing, code coverage by the unit tests and
building the executable file are automated through tools and these steps are called in sequence by
the continuous integration server. The executable file is placed in the artifact repository for further
testing and release. The continuous integration server is configured to orchestrate frequently to
ensure continuous integration of code.

Tools
Jenkins, Bamboo and TFS are examples of continuous integration tools that orchestrate the build
and deployment activities which are in turn automated using respective tools
What is pair programming?
Two programmers coding together on a single machine is called pair programming. One of the
programmer plays the role of a driver who writes clean code, compiles and execute the code. The
other plays the role of navigator who strategizes on design, tests, reviews and refactors code. These
pairs self-organize and switch partners and roles during the day

• Pairing can be done on code which is to be maintained

• Switching partners several times during the day helps
• Form natural pairs, no enforcement
• Allow lot of conversation
• Switch driver and navigator roles
• Good infrastructure for pairing stations
• Maintaining peer balance during pairing is essential (Pairing of senior and junior developers)

The following table summarizes how the twelve principles of agility can be met-