SCRUM FRAMEWORK

INTERNATIONAL CERTIFICATION INSTITUTE TM

www.scrum-framework.com

S CRUM FRAMEWORK
STUDENT BOOK

2022 - 3rd Edition

 Table of Contents

Table of Contents ..................................................................................................................................................... 2

The Agile Manifesto ................................................................................................................................................. 6
The Agile Values ................................................................................................................................................... 6
The Agile Principles .............................................................................................................................................. 6
Agile Methods ...................................................................................................................................................... 7
Key Points............................................................................................................................................................. 7
Scrum Overview ....................................................................................................................................................... 8
Key Scrum Concepts........................................................................................................................................... 10
Project roles ....................................................................................................................................................... 11
Scrum Team ................................................................................................................................................... 11
Interested and Committed ............................................................................................................................. 12
Primary Roles ................................................................................................................................................. 12
SPRINT 0 ................................................................................................................................................................. 14
Specifications in Agile ........................................................................................................................................ 14
Beginning the process ........................................................................................................................................ 14
Outcomes ........................................................................................................................................................... 14
Backlog ............................................................................................................................................................... 15
Accuracy ............................................................................................................................................................. 16
Estimating Effort ................................................................................................................................................ 17
Story Estimation ............................................................................................................................................. 17
Task Estimation .............................................................................................................................................. 17
How? .............................................................................................................................................................. 17
Estimating Time ................................................................................................................................................. 18
Staff Overhead ............................................................................................................................................... 18
Calculation...................................................................................................................................................... 19
Cost / Time / Scope ............................................................................................................................................ 20
Fixe Cost ......................................................................................................................................................... 20
Fixed Time ...................................................................................................................................................... 20
Fixed Scope .................................................................................................................................................... 20
Fixed Cost and Scope ..................................................................................................................................... 21
Fixed Cost and Time ....................................................................................................................................... 21
Fixed Time and Scope .................................................................................................................................... 21
 Fixed Cost, Time and Scope ........................................................................................................................... 21
Start a SPRINT ........................................................................................................................................................ 22
Sprint Planning Meeting .................................................................................................................................... 22
Part 1: Business Specifications ....................................................................................................................... 22
Part 2: Technical Specifications...................................................................................................................... 23
Key Planning Elements ................................................................................................................................... 24
During a SPRINT ..................................................................................................................................................... 26
Daily Lifecycle ..................................................................................................................................................... 26
Task Lifecycle ..................................................................................................................................................... 26
Sprint Backlog ................................................................................................................................................ 27
In progress...................................................................................................................................................... 27
Blocked ........................................................................................................................................................... 27
Testing ............................................................................................................................................................ 27
Done ............................................................................................................................................................... 28
Not Done ........................................................................................................................................................ 28
Development HINTS ........................................................................................................................................... 29
Features ......................................................................................................................................................... 29
Develop .......................................................................................................................................................... 29
Commit........................................................................................................................................................... 29
Transparent .................................................................................................................................................... 29
Test Driven Development .................................................................................................................................. 30
Key Points....................................................................................................................................................... 30
Continuous Integration ...................................................................................................................................... 31
Unit Testing .................................................................................................................................................... 31
Code Standards .............................................................................................................................................. 32
Documentation .............................................................................................................................................. 32
Code Coverage ............................................................................................................................................... 33
Compile .......................................................................................................................................................... 33
Scrum Meeting ................................................................................................................................................... 33
INSPECTION ........................................................................................................................................................ 35
Project Velocity .............................................................................................................................................. 35
Sprint Velocity ................................................................................................................................................ 35
Burndown & Burnup Chart ................................................................................................................................ 36
Progress Problems ............................................................................................................................................. 37
Discovery ........................................................................................................................................................ 37
Scope Creep ................................................................................................................................................... 37
 Plateau ........................................................................................................................................................... 38
Too Many Features ........................................................................................................................................ 38
Tracking Epics ................................................................................................................................................. 39
Finishing a SPRINT .................................................................................................................................................. 40
Sprint Review ..................................................................................................................................................... 40
Sprint Retrospective........................................................................................................................................... 41
 The implementation of business systems may not always go according to plan as requirements
may change due to factors such as a new strategy, target or competitor. Traditional methods of
business management often struggle to cope with these circumstances, necessitating the use of a
different approach.

Agile business management involves a set of concepts and procedures for the day-to-day
management of an organization. As an Agile manager, it is crucial to comprehend, embody and
promote these concepts. By embracing and shaping change within the organization, it is possible to
take advantage of new opportunities and outperform competitors.

Directing the Agile Organization provides a new perspective on business management by

combining first-hand research and in-depth case studies. The book advocates for the use of Agile
processes that have been successfully pioneered in the IT and manufacturing sectors.
 SCRUM FRAMEWORK STUDENT BOOK

The Agile Manifesto

The “Agile Software Development Manifesto” was developed in February 2001, by
representatives from many of the fledgling “agile” processes such as Scrum, DSDM, and XP. The
manifesto is a set of 4 values and 12 principles that describe “What is meant by Agile".

The Agile Values

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

The Agile Principles

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 Time-Scale.

4. Business People And Developers Must Work Together Daily Throughout The Project.

5. Build Projects Around Motivated Individuals. Give Them The Environment And Support
They Need, And Trust Them To Get The Job Done.

6. The Most Efficient And Effective Method Of Conveying Information To And Within A
Development Team Is Face-To-Face Conversation.

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 Maximising The Amount Of Work Not Done – Is Essential.

11. The Best Architectures, Requirements, And Designs Emerge From Self-Organising Teams.

12. At Regular Intervals, The Team Reflects On How To Become More Effective, Then Tunes
And Adjusts Its Behaviour Accordingly.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Agile Methods
The term Agile actually refers to a concept, not a specific methodology. There are many, and
sometimes conflicting, methods that can be used under the Agile umbrella. These include;

• Agile Unified Process,

• Behaviour Driven Development (BDD),

• Crystal Clear,

• Dynamic Systems Development Method (DSDM),

• Extreme Programming (XP)

• Feature Driven Development (FDD),

• Kanban

• Lean Development,

• Rapid Application Development (RAD),

• IBM - Rational Unified Process (RUP),

• Scrum,

• Test Driven Development (TDD),

Key Points
All of the above methods have four key points in common.

1. Iterative design process

2. Continuous stakeholder engagement

3. Aims for quality and reliable software

4. Short development cycles (up to a month) allows to regular delivery of software

This shows that an Agile approach is appropriate in contexts where the outcomes are not known (or
can’t be known) in advance and where the delivery of the outcomes cannot be fully controlled.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Scrum Overview
Scrum is referred to as a "framework" that enables the utilization of diverse processes and techniques
instead of being classified as a process or technique for product development. The Scrum framework
places a significant emphasis on teamwork and establishes distinct roles, events, artifacts, and
regulations. The Scrum framework consists of three primary roles, which include :

• The product owner representing the stakeholders.

• The scrum master responsible for managing the team and Scrum process.

• The team comprising roughly seven members involved in software development.

The Scrum methodology employs a highly adaptable and iterative approach where there is a tangible
outcome for the business at the conclusion of each work Sprint. The resulting output is readily
apparent in the accompanying diagram.

Figure 1 : Scrum Framework

The collection of requirements forming the foundation of a project is compiled into a Project Backlog,
which is frequently revised. The features linked to these requirements are referred to as User Stories.
This correlation is depicted in the diagram below:

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Project

Iterations

Tasks

Figure 2 : Scrum Project Structure

The project's work is divided into time-bound cycles lasting 1 to 4 weeks. During these cycles, both the
project team and the business determine the feasible User Stories in a descending order of priority
that can be accomplished in each cycle, also known as Iteration. This subset of User Stories is
extracted from the Project Backlog and is used as a basis for the planned Iteration Backlog delivery
over the two-week period.

In Scrum methodology, there are three time-boxed meetings that occur during an Iteration, along with
a daily stand-up meeting involving the team, scrum master, and ideally the product owner. During the
Sprint planning meeting at the start of an Iteration, the features that are to be developed during the
Sprint are decided. At the conclusion of the Iteration, there are two additional meetings - the Iteration
review and Iteration retrospective - where the team assesses the product, demonstrates the
software's functionality, reflects on the Iteration process, and endeavors to improve it.

After concluding a Sprint, the next set of User Stories is chosen from the Project Backlog, and the
process is restarted. Burn rate is carefully tracked to determine when funding will run out.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Key Scrum Concepts

Concept Description
Project Discreet set of end user requirements that have been
grouped, prioritised and funded.
Requirement The end user statement that outlines their
information need.
Sprint A Sprint is a 1 to 4 week time-boxed event focused on
the delivery of a subset of UserStories taken from the
Project Backlog.
Project Backlog The Project Backlog is the current list of User Stories
for the Project. User Stories canbe added, modified
or removed from the Backlog during the Project.
Sprint Backlog Subset of User Stories from the Project Backlog
that are planned to be delivered aspart of a Sprint.
User Stories The User Story is a one or two line description of the
business need, usuallydescribed in terms of features.
Tasks Tasks are the activities performed to delivera User
Story.
Technical Debt This refers to items that were either:
• missing from the Planning meeting;or
• deferred in favor of early delivery.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Project roles
Scrum Team
The project team is an autonomous group capable of independently fulfilling a customer's
requirements. Therefore, the team must have a cross-functional mix of skills and knowledge across
the data, tools, and infrastructure domains.

A typical project team usually consists of the following members:

• Product Owner

• Scrum Master

• Architects/Analysts

• Designers

• Developers

The characteristics and responsibilities of the project team are as follows:

• 7 ± 2 (5 to 9) resources allocated full-time to a Sprint

• Cross-functional in nature across skills, applications, data, and organizational knowledge

• Empowered to be self-directed

• Accountable for delivering the product

• Determining the tasks required to deliver each feature

• Estimating the effort required for each task

• Developing the features

• Resolving issues

It is ideal for the project team, including the product owner, to be co-located.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Interested and Committed

Those who have an interest in the software development process are known as "Interested
Roles," and while they should be kept up-to-date on progress, they do not have the same level of
responsibility or involvement in the development process as Committed Roles. Interested parties may
include Users, Customers, and the Product Owner.

On the other hand, Committed Roles are responsible for carrying out the actual software development
work. They are the ones who "do" the work, and include the Scrum Master, the Team, and Testers.

Primary Roles
Business
Users

Scrum
Master
Technical

Figure 3: Business vs Technical roles

www.scrum-framework.com
SCRUM FRAMEWORK STUDENT BOOK

Role Primary Responsibility Typical Does Not

Users • Use the software • There are no typical • Set Scope
Interested Role • Identify issues & users. • Test Work
• Provide feedback
Customers • Define, start and • Internal managers • Direct Work
Interested Role endthe project • External Clients
Product • Manage the product • Project Manager • Manage the
Owner backlog • Product manager Team
Interested • Set the scope • Customer
Role • Approve Releases
Scrum Master • Manage the Agile • Project manager • Prioritise
Committed process • Team Leader features
Role • Report on progress • Team member
Developers • Develop features cross functional • Prioritise
Committed • Resolve issues • Developer features
Role • Designers
• Writers
• Administrators
Testers • Test • Existing developers • Test their
Committed • Approve or reject • Dedicated testers owncode
Role features for
release

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

SPRINT 0
Specifications in Agile
Despite what some may believe, having a well-defined specification or backlog is crucial before
embarking on an agile project. Such a specification can bring several benefits to the project, including:

• Reducing risk and uncertainty

• Improving decision-making processes and ensuring alignment with long-term goals

• Enhancing cost planning, including staff hiring

• Prioritizing research and information gathering

In summary, developing a detailed specification or backlog can help to mitigate potential issues,
facilitate effective planning and decision-making, and ensure that the project stays on track towards
its long-term goals.

Beginning the process

In contrast to traditional waterfall methods, the specification phase in an agile project is typically brief,
lasting no more than one or two days, and the entire team should be present at the outset. During this
time, the customer should be clearly informed of their role. The design should include the following
elements:

• A problem statement that requires attention

• Business objectives, outcomes, and benefits sought from the project

• Key stakeholders identified

• High-level business requirements

• Architectural and technical scope

• Testing requirements

Outcomes
The following are the results of Project Initiation, also known as Sprint 0:

• Form the team and establish its composition

• If the product owner is not already a team member, find and educate them

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

• Start the product backlog with basic information, letting customers add requirements gradually as
the project progresses.

• Assess the product backlog.

• Determine the duration of the Sprint, which can vary from one day to four weeks, with the goal of
achieving a release-worthy outcome. Short Sprints can help avoid overtime.

• Include any team training as tasks in the backlog.

Backlog
The backlog is a collection of User Stories (features) that outlines the product requirements. The
Product Owner is responsible for creating and prioritizing User Stories based on factors such as
dependencies and business value. The high-priority User Stories for the upcoming Sprint must be
detailed enough for the team to develop a solution and should be small enough to be completed
within two weeks. Each User Story should adhere to the INVEST principles as defined by Bill Wake,
which are as follows:

• Independent: Each Requirement should be self-contained with minimal dependencies on other

Requirements.

• Negotiable: The Customer can change a Requirement up to the point it enters the Sprint Backlog.

• Valuable: Each Requirement should deliver a measurable benefit to the Customer.

• Estimatable: Each Requirement should be estimable by the Team.

• Small: Each Requirement should be completed within a few days or a single Sprint.

• Testable: Each Requirement should have appropriate quality control and quality assurance metrics
for Customer validation.

Each feature should include the function, priority, estimated development effort, and risk estimate (0-
100%) based on the team's level of confidence in the estimate. It can be beneficial to structure each
User Story with the following format:

As a [role], I want [goal/desire] so that [benefit].

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

The User Story typically involves an end-user, referred to as [role], who may differ from the Customer.
The [goal/desire] outlines the specific deliverables required for the User Story, while the [benefit]
provides context and explains the underlying reasons or purpose.

Accuracy

Figure 4: Estimate Accuracy over time

It should be noted that the amount of effort required to enhance the precision of an estimate
rises exponentially. However, in Agile methodology, our focus lies only on the initial estimation. By
keeping Sprints brief, we can promptly scrutinize and address any deviations in the estimate. For
further details, refer to the Burndown chart section.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Estimating Effort
Story Estimation
A Story Point is a singular number that aims to encompass all the work necessary for the entire
team to create the final product. Hence, estimating using Story Points requires the participation of
cross-functional team members possessing the necessary skills and knowledge of the Business
Intelligence Platform data, tools, and infrastructure during the Sprint Planning meeting.

These points are employed to provide high-level estimates of User Stories based on similar
previous Sprints assuming that the project team, data, and infrastructure are relatively constant. Over
time, the Story Point size for a given project team will eventually stabilize.

All Stories should be assigned estimated effort or cost to implement using a modified Fibonacci series,
such as 1, 2, 3, 5, 8, 13, 20, 40, and 100, to encourage the division of features into the smallest
possible tasks and provide a more practical estimate range.

Task Estimation
Task estimation is performed at the Sprint level. During the Sprint Planning session, the team
breaks down the User Stories into their composite tasks to determine how they will be delivered. This
process of solution decomposition may reveal additional or more complex tasks that impact what was
planned to be delivered during the high-level Story Point-based estimation. In such cases, the scope of
the Sprint can be renegotiated with the product owner. These task estimates provide an indicative
idea of the amount of time they will take in an ideal world.

How?
There are four ways of estimating tasks.

1. First is the Expert Opinion, where the team member with a specific understanding or who
is most likely to develop the task can provide a more precise effort estimate.

2. Second is the Comparison method, which involves comparing a task to another already
estimated task.

3. The third is the Components method, where if a task is too large to estimate accurately, it
is broken down into small sub-tasks.

4. Lastly, the Planning Poker method is used, where estimates must not be discussed during
the conversation to avoid anchoring. A timer may be used to ensure that discussions are
structured.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Each person lays a card face down representing their estimate of the task, and then
simultaneously turns their cards over. Individuals with high and low estimates are given
the opportunity to discuss their estimates before anyone else can speak.

The estimation process is repeated until a consensus is reached.

Figure 5: Planning Poker Cards

Estimating Time
The process of converting an approximate cost into an approximate time is straightforward,
involving the utilization of two main adjustments - staff overhead and estimate accuracy (or risk).

Staff Overhead
This is a modifier expressed as a percentage that accounts for the availability of staff to
perform particular tasks on a project. It considers various factors, including estimated leave, breaks,
illness, and scrum meetings. Although the typical industry standard modifier is 25%-40%, you can
adjust it based on your project's specific requirements. To determine staff overhead, follow this
procedure:

working hours = (hours per day * days per Sprint * staff) – planned leave

project hours = sum of actual (from last Sprint)

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

staff overhead = (working hours/project hours) – 1

Calculation
Story Cost x (Staff Overhead + 1) x (Estimate Risk + 1)

e.g.

4 x (25%+1) x (50%+1)

= 4 x 1.25 x 1.5

= 5 to 7.25 hours

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Cost / Time / Scope

“How much is this going to cost?” - “As much as you're willing to spend.”

“How long is this going to take?” - “As long as it necessary.”

“What am I going to get?” - “Whatever you tell us you want.”

Fixe Cost
When a customer requests a fixed price quote before starting the project but remains flexible about
the deliverables and timeline, the following approach should be taken:

• Prioritize tasks based on customer needs to ensure short-term budget constraints are met, but
be aware that this may impact long-term efficiency.

• Break down the project into short Sprints of 1-2 weeks to reduce the risk of cost overruns and
ensure timely delivery.

• Keep a close eye on velocity and burn rate as these are important indicators of cost.

Fixed Time
When a customer requires delivery by a specific date but is open to changes in scope and cost, follow
these guidelines:

• Prioritize user stories based on their business value to maximize the number of completed
stories in each Sprint. High business value stories with moderate-high priority should be given
priority.

• Ensure the Sprints have a fixed duration to prevent delays and project timeline extensions.
Extending a Sprint will push out the final delivery date.

Fixed Scope
If a customer requests a fixed set of deliverables but is open to flexible timelines and delivery costs,
which is also referred to as "heavy agile," do the following:

• Prioritize the backlog definition and estimation during Sprint 0 to ensure precise scope
definition.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Fixed Cost and Scope

When a customer requests a fixed price quote for a specific set of deliverables, but is flexible on the
final delivery date, the following guidelines can help:

• Increase the estimate risk during Sprint 0, so that your project quote includes allowances for
unexpected delays that could impact your cost to deliver.

• Update the delivery date as necessary.

Fixed Cost and Time

If the customer requires a fixed price quote by a specific time and is flexible on the scope of features
to be delivered, you can follow these guidelines:

• Determine the total cost per Sprint - this makes it easier to provide a quote to the customer.

Fixed Time and Scope

To address a customer's request for a fixed set of deliverables by a fixed deadline, with flexible total
cost, as well as flexible time and scope, you can consider the following strategies:

• During Sprint 0, allocate work to Sprints, which will establish the delivery schedule.

• Include extra Sprints in the schedule as a buffer to accommodate unexpected issues or

technical debt.

• Increase the team size by 3-4 Sprints before the project's end, if necessary, to ensure timely
completion of the set of features.

Fixed Cost, Time and Scope

If the customer does not allow any flexibility in the project, it may not be suitable for an agile
methodology. In such a case, it may be best to consider using a more traditional project management
approach like PRINCE2, as even agile methods require some level of flexibility to be successful.
Alternatively, it may be necessary to cancel the project altogether.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Start a SPRINT
Sprint Planning Meeting

Figure 6: Sprint Planning

Before each Sprint, the Sprint Planning Meeting is conducted to facilitate discussions between
the customer and developers regarding the necessary requirements and tasks for the upcoming
release. This particular stage in the Scrum process focuses on determining the specific delivery targets
for the Sprint and outlining the Sprint backlog. It is important to note that the Sprint Planning Meeting
should not exceed 8 hours (pro rata for 4 weeks).

The responsibility of updating the Project Backlog for the meeting lies with the Product Owner and
Scrum Master, who must ensure that the User Stories are clarified, prioritized, and, in some cases,
investigated for feasibility. This process must also consider any inherited technical debt from previous
Sprints.

Part 1: Business Specifications

The first part of the Sprint Planning Meeting is dedicated to converting the features from the
backlog into an attainable goal for the upcoming Sprint. The Product Owner plays a key role in this
process by prioritizing the tasks, conveying the required scope of delivery, providing the business
context and priority, and addressing any queries the project team may have to help them with their
solution decomposition and estimation steps. This part of the meeting should not take more than a
quarter of the allocated time.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

To enable the project team to have enough time to consider solution options for discussion during the
workshop and prepare clarification questions for the Product Owner, it is important to distribute a
copy of the Project Backlog before the Sprint Planning Meeting.

The typical participants in this session are:

• The Product Owner.

• Scrum Master.

• Team, and Testers.

Part 2: Technical Specifications

The second stage of the Sprint Planning Meeting is typically focused on technical aspects and
does not involve the Product Owner. This stage is known as solution decomposition and estimation,
and its purpose is to estimate the effort required for all the features in the release, and potentially
create test cases.

The steps involved in this process are represented in the following diagram:

Determine
Select user Tasks to
Story Deliver User
Story

Agree
Assign the Technical
Task Dependencie
s and Order

Assess the Estimate the

Risk effort
Associated required to
with the Task complete
Estimate each Task

Figure 7: Design and Planning Workflow

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

It is advisable to break down large tasks into smaller ones that can be completed within a day,
while tasks that require waiting should be separated into different tasks. Research tasks should be
given a high estimate risk to facilitate accurate tracking and velocity calculation.

For intricate User Stories or those with numerous interdependencies, it may be necessary to split the
task decomposition and estimation process over two days and allow team members to consult
external parties for feasibility and estimating input. It is essential to keep in mind that tasks can be
created, but features cannot be.

The individuals involved in this session are:

• The Scrum Master

• The Team

• The testers

NOTES
• Prepare beforehand.

• This is a creative, problem-solving process. Encourage brainstorming.

• Ensure the planning room has plenty of paper, a whiteboard and a computer with Google access.

Key Planning Elements

Planning Element Description
User Story The User Story is a description of the business need, usually
expressed as afeature.
Story Idenifier Every User Story will be assigned a uniqueidentifier for tracking
purposes.
Task A task is typically a single activity that can bedescribed in one
sentence that contributes to the delivery of a User Story.
• Generally a task takes no longer than 4-8hours of effort to
complete
• There may be one or many Tasks perUser Story
• The task can only be assigned to andowned by one person
at a time
Task Identifier A Unique identifier will be assigned to trackeach Task, and show
which User Story they are associated with.

www.scrum-framework.com
SCRUM FRAMEWORK STUDENT BOOK

Project Function This describes the architectural layer where the Task activity will be
performed.
Assignee This is the person who will be responsible for delivering the task.
This can done at any point in the Sprint. The person assigned to
the completion of the Task may also change
at any point in the Sprint.
Estimate The estimate in hours is the amount of effort the team agrees is
required to complete the specified Task. The estimate includes:
• Analysis
• Build
• Unit Test
• Migrate from DEV to TEST
• Integration Testing
Documentation
Estimate Risk This is a measure of the confidence level associated with the
Modifier estimate provided and represented as a numeric modifier.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

During a SPRINT
Daily Lifecycle
The typical team activities in a day involve the following steps:

1. Choosing the next task to work on by team members

2. Carrying out the task as instructed

3. Sharing the completed task with the rest of the team and committing to it

4. Creating and running tests to ensure successful completion, along with documentation and
unit testing. It's important to finish verification before transferring the deliverable from
DEV to SIT.
The person responsible for a task can change during any of these stages. To complete the assigned
task, team members will proactively collaborate with colleagues and relevant internal parties,
including quality assurance and review.

The daily Scrum Meeting governs the daily lifecycle of these activities.

Build Commit

Done

Testing
Test-Driven
Continuous
Developme
Integration
nt Deploy

Highest
Priority
Task

Figure 8: Work Lifecycle

Task Lifecycle
A minimum of four different stages will be passed by a task throughout its lifespan when
utilizing Kanban. To ensure visibility to the team, product owner, and customer, each task and stage
can be displayed on a card wall or an integrated dashboard.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Backlog Build Test Done

Figure 9: Basic Task Lifecycle

Backlog Analysis Build Test Stage Doc Release Done

Figure 9: Complex Task Lifecycle

Sprint Backlog

The Sprint Backlog consists of User Stories that have been mutually agreed upon by the
Product Owner and project team for delivery in the current Sprint.

These User Stories are then further divided into tasks and added to the Sprint Backlog. The project
team members prioritize and sequence the tasks, selecting the next one to work on and moving it to
the "In Progress" state.

In progress

Items that are currently being worked on are referred to as "In Progress" Tasks. These can
encompass a range of activities, such as analysis, building, unit testing, and documentation. Once a
task has been completed, it is moved to the "Testing" state. If the task involves code-based artifacts,
they will be transferred from the development environment to the test environment for further
testing.

Blocked

When Stories or Tasks have dependencies outside of the project team that are hindering
progress, they are considered "Blocked." To bring attention to these issues and prompt escalation and
resolution, they are moved to a dedicated holding state and flagged for the Scrum Master and Product
Owner.

Testing

The team's dedicated testing specialists are responsible for performing testing in this context.
However, developers are expected to conduct unit testing.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Done

Tasks are considered "Done" when the following criteria are met:

• Code has been developed, meets the required standards, and has been checked into the
source control system

• Unit tests have been written and passed

• System testing has been conducted and passed

• The Quality Assurance team has reviewed the task

• The task builds without any errors for deployment

• Relevant documentation, including diagrams, has been created or updated and shared

At the end of a Sprint, User Stories selected by the team are categorized as either "Done" or "Not
Done" based on the completion status of their associated prerequisite Tasks. Completed User Stories
are then presented to the Product Owner in the Sprint Review for acceptance and sign-off.

Not Done

Tasks that remain incomplete are evaluated in relation to their associated User Stories to
determine whether the Story can still be considered delivered. These incomplete tasks may be
addressed in various ways such as rolling them into a new User Story for the following Sprint, treating
them as technical debt, or deciding they are no longer necessary and removing them from the
backlog.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Development HINTS
Features

Select the highest priority feature from the Sprint backlog and let developers choose their
tasks rather than assigning them. It's possible to update the backlog mid-Sprint if necessary changes
arise. Commence development.

Develop

Agile methodology offers recommendations for enhancing the development process, which include:

• Pair Programming: This involves two developers collaborating, with one serving as the coder
and the other as the reviewer. The roles should alternate regularly, and pairs should switch
each day.

• Code Standards: A uniform coding style should be implemented, encompassing

documentation, naming conventions, whitespace, and so on.

• System Metaphor: All classes and functions should be named in a way that clarifies their
intended purpose.

Commit

Everyone must commit every day, and should never commit broken code. (Continuous Integration)

Transparent

Transparency is crucial in Agile, fostering open communication among the product, team, and
customers. The following options are available to customers:

• Attend scrums, but refrain from speaking. Instead, questions should be directed to the Product
Owner or Scrum Master. Alternatively, recordings of the scrums can be provided to the
customers.

• View the current state of the product and Sprint backlog.

• Observe the status of each task via a card wall or integrated dashboard.

• Access a test version of the software from the development environment.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Test Driven Development

Key Points

The Customer and Developer collaborate to write tests before writing the code in TDD. It is
recommended to write both automated unit tests and user acceptance tests. IEEE 829 and IEEE 1008
can be used to document and write tests without any problems.

TDD enables the team to demonstrate the project's progress and proximity to completion,
empowering customers and product owners to make informed decisions about the project.

Test Coverage

The tests should cover :

• Software functions,

• Boundary cases,

• User interface,

• User experience,

• Non-functional components,

• Performance
Test Types
There are 4 types of tests that can be written.

1. Defect

2. Functionality
3. Usability

4. Data

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

TDD in Development

1. Create a Test

2. Add test to the test Catalog

3. Write Code

4. Run the tests (all of them)

5. Cleanup the code as required (Refector)

Figure 10: TDD Workflow

Continuous Integration
Unit Testing

Conducts automated tests in order to identify software defects based on predetermined criteria.

• Generates tests for all classes and functions.

• Creates tests for all possible parameter combinations.

• Creates tests for all exceptional scenarios.

• Develops tests to examine the database for logical errors.

• Establishes tests to detect interface defects using Selenium.

• Stores tests in the version control repository.

• Runs tests in a replica of the production environment.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Figure 11 : Unit Test Screenshot

Code Standards

Inspect the developed code for deviations from the internal code standard

• Check for correct inline documentation (docblock)

• Check for correct variable naming conventions

• Check for correct whitespacing conventions

• Check for complex code that may require refactoring

• Check for incomplete or unused functions

Figure 12: Code Standards Screenshot

Documentation

The following should be commented;

• Files

• Classes

• Functions

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

• Class Variables

Complex Structures Comments should contain;

• Description

• Author

• Usage

• Parameter description

• Return description

• References to other functions

• Copyright (file comments)

Code Coverage

Determine the percentage of software covered by unit tests and present the result on the display.
Strive to achieve a code coverage rate between 80% and 90%.

Figure 13 : Code Coverage Screenshot

Compile

Run any compile or make scripts. All commits should compile.

Scrum Meeting
The daily stand-up meeting is designed to maintain a consistent focus on incremental progress
and delivery, which is then demonstrated to the Product Owner. Its purpose is to be informative,
interactive, and ensure that the team has a shared understanding of what is being worked on, who is
working on it, and its current status.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

This meeting involves the Product Owner, Scrum Master, and the project team, and it is time-limited
to 15 minutes. Each participant should answer the following three questions:

1. What progress did you make yesterday?

2. What do you plan to achieve today?

3. What obstacles may prevent you from achieving your goal today?

The Scrum Master is responsible for addressing any obstacles or impediments identified by the team.

Figure 14: Daily Standup meeting

For projects involving several teams, it's advisable to conduct a "scrum of scrums" session, limited to
15 minutes, following the initial scrum. This gathering should assemble Scrum Masters from various
teams to respond to the same set of three questions as before, but this time, in relation to their
respective teams.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

INSPECTION
Project Velocity

The capacity and resulting output of a project team over time can be determined through a metric
called Project Velocity, which specifically measures the estimated number of User Stories that the
team can deliver throughout the project. To determine Project Velocity, there are several methods
available:

• Historical values can be used by assuming that previous User Stories have similarities in terms of
relative size, data, infrastructure, etc.

• By running a Sprint, the estimate can be derived based on the observed Velocity over 2-3
Sprints.

• In cases where historical values are not available and running multiple Sprints is not feasible, a
forecast can be made by disaggregating User Stories and estimating at a Task level.

To represent the project's scope, any changes made to it, and the planned and actual delivery of User
Stories, a burndown or burnup chart can be used. This chart can also be utilized to forecast when the
project team will complete all the User Stories in the Project Backlog.

Sprint Velocity

The capacity and resulting output of a project team for a particular Sprint, which refers to the
number of User Stories that can be delivered over the next two weeks, is determined by Effort-based
Velocity. This velocity can be calculated as an average at the team level, or if there is significant
variation in working hours, as an aggregate of the individuals.

Sprint Velocity is measured in terms of Potential and Forecast capacity:

• Potential Sprint Velocity is the total allocated working hours for the project team.

• Forecast Sprint Velocity takes into account Staff Overhead and is the estimated productive
workable hours that can be attributed to Sprint tasks.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Burndown & Burnup Chart

Figure 15: Example Burndown Chart

The Burndown and Burnup charts are useful tools for managers and customers to track progress
towards the release, enhance future estimates, and recognize problematic trends at an early stage. It
is recommended that the Burndown (or Burnup) chart is made accessible to all project stakeholders.

Figure 16: Example Burnup Chart

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Progress Problems
All about risk mitigation

Discovery

Figure 17: Problem Burndown (Discovery)

It is important to closely monitor progress during the Sprint and be prepared to address any issues
that arise or adjust estimations as needed. If necessary, it may be helpful to review the tasks in the
current Sprint.

Scope Creep

Figure 18: Problem Burndown (Scope Creep)

It is necessary to determine the individual responsible for adding tasks during the release phase and
take measures to prevent this action from occurring again.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Plateau

Figure 19 Problem Burndown (Plateau)

Take a look at the tasks in the Sprint and assess whether they are more challenging than anticipated or
if there are unforeseen staffing problems.

Too Many Features

Figure 20: Problem Burndown (Too Many Features)

If the features are proving to be more challenging than expected, it may be necessary to reevaluate
the estimation process and consider removing certain tasks from the Sprint.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Tracking Epics

Figure 21: Problem Burndown (Tracking Epics)

Individual stories are too large and difficult to track. Keep each task under 1 day of work.

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

Finishing a SPRINT
Sprint Review
Following the Sprint, it is the responsibility of the Scrum Master to conduct a Sprint Review meeting
where the completed User Stories are presented to the Product Owner and, if applicable, the
Customer for final approval before release to production. As the Product Owner has been actively
involved in the development and verification process on a daily basis, this step should be relatively
straightforward.

Figure 22: Sprint Review

The meeting should involve the following participants:

• Product Owner

• Scrum Master

• Project Team

During the meeting, the team should:

www.scrum-framework.com
 SCRUM FRAMEWORK STUDENT BOOK

• Demonstrate the completed work to the Product Owner

• Assess the work that was finished

• Evaluate the work that was not completed. Any User Stories that were not completed may be
carried over to the next Sprint.

Sprint Retrospective
Once the Sprint Review is complete, the Scrum Master should organize a Sprint Retrospective meeting
to examine and enhance the Sprint process itself. During this session, the team should:

1. Reflect on the previous Sprint

2. Implement any necessary process improvements

3. Identify the successes of the Sprint

4. Discuss areas that could be enhanced in future Sprints

The Sprint Retrospective enables the team to contemplate the completed Sprint and drive ongoing
process improvement by applying the lessons learned.

Figure 23: Spring Retrospective

www.scrum-framework.com
 SCRUM FRAMEWORK
STUDENT BOOK
INTERNATIONAL CERTIFICATION INSTITUTETM

www.scrum-framework.com