Académique Documents
Professionnel Documents
Culture Documents
SCRUM FRAMEWORK
V1.0
SCRUM FRAMEWORK
Scrum is an Agile framework for incremental product development that focuses on what is truly
important for the client; it requires:
The team finally builds a potentially shippable product increment (properly tested) in every
iteration that is something that can be shown as finished to the clients in order to check against
their expectations. This must be of high enough quality to be given to final users but it does not
necessarily mean that it has to be made public.
The potential Product Increment must meet the Scrum Team's current Definition of Done, and
the Product Owner must accept each component of it.
Business and IT working in different worlds and not following a shared goal.
Releases taking too long to be built.
Stabilisation stages taking too long.
Changes hard to make and quality falling.
People demotivated, having no trust in each other or paralysed when trying to analyse a
complex problem.
Scrum provides a platform for people to work together effectively and makes visible every
problem that appears in its way to empower the finding of some new and creative solutions.
In order for Scrum to work, it needs some positive habits for people to follow, such as:
Develop a product that meets customer expectations in a fixed (time-box) and small
period of time with the idea to get feedback.
Find motivated people that perform joint approaches to create synergies between
Business and IT; increase productivity and creativity; and continually improve the way
they do things.
Scrum values are used at Team level and promote inclusiveness of people to work together as a
single unit moving towards a common goal and a shared commitment, it focuses on rapid
cycles, time to reflect and improving what is done. Everything we do is based on Agile values
and principles.
Focus
Respect Courage
Scrum
values
Commit Openne
ment ss
Scrum also provides a clear set of additional values to be followed when developing a product and
help mitigating risks resulting from erratic behaviours on the system.
Focus - because you focus on only a few things at a time, you work well together
and produce excellent work. In this way, you always deliver valuable items sooner.
Courage - as you are not alone, you feel supported and have more resources at your
disposal. This gives you the courage to undertake greater challenges.
Openness - as you work together, you practice expressing how you're doing and
what's in your way. You learn that it is good to express concerns so that they can be
addressed.
Commitment - because you have great control over your own destiny, you become
more committed to success.
Respect - as you work together, sharing successes and failures, you come to respect
each other and to help each other become worthy of respect.
It is generally a good practise to encourage discussion but never to impose it- to allow people to
know their benefits.
Small cycles with functionality ready-to-use: usable product that meets the
clients business goals (working software/product).
Visual Management: tools to create an environment where things are obvious from
the minute you walk into the area.
Product Owner requires a minimum of 50% dedicarion to support the operational needs of a Scrum
Team. Rest of time should be devoted to work on Product Management, customer needs, competitors
analysis, etc.
A Scrum Master is the key person who helps achieve the benefits of Scrum. These
are some of their responsibilities:
Dedication for this role may be nearly complete for a team of 9 people. Equivalently, for a team of 4-
5 people's, dedication may be up to 50%.
We generally recommend finding a Scrum Master with a good command of soft-skills and
interpersonal skills with some knowledge of Agile and Lean Software Development. Teamwork,
change management, leadership, coaching, motivation and emotional intelligence are also a plus
that through coaching, the Scrum Master can improve on.
Remember that she is a very proactive person that shares the teams difficulties and experiences,
works on their resolution and advocates transparency in all the duties.
- Involve the people who will be part of the Team during its creation so
they can make decisions about it.
- Make sure Teams are stable (over 2-3 years), so that its members
engage and learn from each other and understand their needs.
Extended Team
Extended Team
Project Manager
This is role is still needed due to the complex environment and that the
organization is on its way to agilization. His main responsibilities are:
Project reporting.
Stakeholder
He has a real interest or stake in the project and can be a direct manager of the
Team members, the people providing funding for the project, a group of users,
etc. This is what he does:
Avoids distracting the Team during a Sprint after the Team has
made a forecast for the Sprint.
A Vision is Created for the product and an initial Product Backlog is defined by
Business; this is basically a list of goals and high/medium level features feasible to be
developed. Many techniques are used during this stage to prioritise and decide what is
worth doing.
A Release Planning meeting is carried out in order to decide what is needed in each
Product Increment and Release and roughly decide what is going to be developed in
each Sprint.
Before the Sprint starts, the Product Owner selects a set of features that are related to
a specific Goal and presents them to the Team during a Sprint Planning meeting.
The Development Team examines the requirements, negotiates and agrees on the things to
be developed (it is not unusual to use Story points and Average Velocity to decide what to
take on-board (check chapter 4, Agile Requirements for more details); this list of functionalities is
called Sprint Backlog. As the Team agreed on them, they can start breaking them into smaller
tasks.
During the Sprint, there is a daily meeting called Daily Scrum, which is time-boxed to a
maximum of 15 minutes where the Team provides their tasks status and raises a flag in case
there is any impediment. Meanwhile, the Scrum Master is responsible for solving any roadblock
that may arise.
When the Sprint is finished, the features are presented to the Product Owner as
working and tested software and he approves what was shown in order to be included in
the Product Increment if necessary. This last meeting (Sprint Review) gives a lot of feedback
to everyone and helps defining new priorities for the upcoming Product Backlog items.
Finally, a Retrospective meeting is held in order to improve the whole process, including
everyone involved and the Company.
PRODUCT BACKLOG
The product backlog is simply a list of work items that need to be done over time. It is a core
element in Scrum and contains a prioritised list of ideas for the product and it is the single
source from which all requirements flow. This means that all work the Development Team does
come from here.
Every idea, enhancement, bug fix, documentation requirement is a Product Backlog item and each
of them includes a description and an estimate. The Product Owner is responsible and accountable
for maintaining the Product Backlog. Requirements are emergent, meaning that you dont and
cannot know up front every detail about what is needed in the product. Having that in mind, consider
the following:
- The Product Backlog is a living document and requires constant refinement; many new
items will be added over time; existing items split to smaller items or removed.
- A day-to-day task for the Product Owner is to negotiate with stakeholders and the Team in
order to get the best possible scenario for the product.
- Items need to be sized in order to determine the likely relationship between value, time and
cost.
- Items might change as their relative values could be seen differently today from yesterday.
We generally use User Stories to express the content of a Product or Sprint Backlog item; check
Chapter 4 (Agile requirements) for more details.
With the Sprint Backlog in place, the Sprint begins, and the Development Team develops the
new Product Increment defined by the Sprint Backlog.
If a previously agreed item cant be finished during the Sprint, the Team would not get the
points from it, the implementation will be removed, taken back to the Product Backlog and a
negotiation with the Product Owner will start to potentially include the feature in a near future.
PRODUCT INCREMENT
The most important Scrum artefact is the Product Increment. Every Sprint produces one, it
means, something with high enough quality potentially, can be given to the clients. The
Product Increment must meet the Scrum Team's current Definition of Done, and each
component of it has been accepted by the Product Owner (check more about Definition of
Done in Chapter 4, Agile requirements).
As we have seen, the Sprint is the heartbeat of the Scrum cycle. It starts with a Sprint Planning
and ends with a Sprint Review and Retrospective. Each day during the sprint, the team holds a
Daily Scrum meeting.
The team alone decides what it can deliver in the sprint, taking into account the sprint duration,
the size and current capabilities of its members, its Definition of Done, actions decided during
the Retrospective and anything else that could affect the Team performance. The Product
Owner must answer questions to clarify what she wants and the Scrum Master must ensure that
any other stakeholder needed to help the team is available.
Any new backlog item, for inclusion in the current Sprint and not previously estimated, needs to
be sized immediately during this meeting.
At the end of part 1, the team makes a forecast to the Product Owner what they believe they
can deliver in the form of running and tested features
In the 2nd part (How will be accomplished), the team collaborates to create a high-level
design of the features it has forecasted to deliver. An outcome of this session is a more detailed
Backlog, or the list of tasks that the team collectively needs to execute in order to turn the items in
the selected Product Backlog into running tested features. This set of tasks is called the Sprint
backlog and is most often represented on a Kanban board.
During the second part, the team may have additional questions regarding the requirements and
any potential issue should be immediately communicated to the Product Owner.
This core practice in the Scrum framework is time-boxed to no more than 15 minutes. Attendees
find here brief clarifying questions and answers, but there is no discussion of any of these topics
during the Daily Scrum. However, many teams meet right after the Daily Scrum to work on
any issues that have come up.
Only the Development Team members speak during this meeting. Other interested parties can
come and listen in. The daily Scrum meeting is NOT for reporting progress to the Scrum Master,
Product Owner or Management. It is a communication meeting within the Development Team for
creating synergies. The aim of this meeting is directed solely at helping the team as a whole
deliver the next item in the backlog and that any impediments to doing this work are removed as
quickly as possible. The Scrum Master should also ensure the meeting is restricted to 15 minutes.
I moderate the meeting in order to keep it productive (to bring value to all attendees) and
not last more than 15 minutes.
Detect who had an issue, is available/free to help/inform the rest about problems or
roadblocks.
Identify what is ready.
Know who to contact after the meeting in order to remove roadblocks.
You can also use a story-by-story approach considering the effort of the whole
team:
The Sprint Review includes a demonstration of the new features the team has completed during
the sprint and its primary purpose is to inspect what the team has delivered, accept them
partially or totally, and gather feedback from the attendees to adapt the plan for the
succeeding sprint.
It is a good time to review Product Backlog Items and re-prioritise them based on the
feedback acquired.
Every interested part should be invited to the sprint review. Have in mind that Sprint reviews have
many possible outcomes including cancellation of the project.
The main point of discussion is the Product Increment completed during the Sprint. This is
generally an informal meeting to take a look at where you are and to collaborate on how
everyone might go forward. All people in here have input and can give an opinion.
Using the Product Increment, Product Owner checks the expected stories and each
acceptance criteria to make sure the features run as expected. If that is the case, the User
Story/Stories are accepted one by one.
During this meeting, everyone gives feedback and the Product Backlog is usually changed/updated.
The Sprint Review also gives everyone an overview of the current features.
These are the activities to do in order to maintain a proper Backlog and run a refinement session:
The idea of a Product Backlog Refinement activity is to prepare for the upcoming Sprints. The
refinement activity gives special attention to preparing items that are coming closer to
implementation. There are many things to consider, including but not limited to:
Each item entering the Sprint should ideally represent an increment of "business
value".
The Development Team needs to be able to build each item within a single Sprint.
Everyone needs to be clear on what is intended.
For simplicity, this activity can be split in 2 parts, the first one focuses on adding new items,
analysing or splitting Epics and adding new Acceptance criteria to them. The second part of
the meeting focuses on taking the closer to development items and going down into a little
bit more detail. This last part makes sure that the User Stories closer to be implemented meet
the Definition of Ready. Check chapter 6 (Agile Planning) for a detailed explanation of a Sprint
Planning meeting.
Read more about Product Backlog Refinement and Acceptance Criteria in chapter 4.
Dont forget that on a regular basis, the Product Owner maximizes utility to be developed and
the ROI of the project by re-planning goals/requirements during a meeting called Product
Backlog Refinement.
The advantage here is visible when the product scope changes, as the line makes it clear that
something was added or removed.
The Definition of Done must always include the notion that the Product is of high enough quality
to be shippable.
Development
- Developed requirements
- Unit testing are successful
Testing
- Classes in the repository
- Build and Deploy (integration environment)
- Integrated testing are successful at integration environment
UAT
- The code is deployed at testing environment
- User Accepting test passed successful
Deployment
- Prepare the deploy at production environment
- Deploy at production environment
- Execute testing (optional)
I can also bring to your consideration the Definition of Sprint Backlog Readiness in use by our
team:
Impediments are generally gathered during the Daily Scrum and prioritised after the meeting.
You can also reserve a place on the Kanban board to group items and make them visible.
Just like requirements, improvements items need to have an Acceptance Criteria; it means, a
clear definition of what is needed to consider them solved.
REMEMBER
Scum values need to be followed.
None of the main roles and responsibilities are optional.
Everyone should understand what Scrum is, its artefacts and how a time-box works.
A clear and feasible strategy needs to be drawn before implementing Scrum.
BENEFITS
IT and Business work together following a common vision and goal.
Scrum reduces the time to market and keeps people engaged and motivated.
Focuses on what a client really needs.
Allows stakeholders to review what is produced in small iterations.
Gives quality time to teams to reflect about their practises.