Scrum and Agile Software

Development Model

Introduction to Scrum
Scrum is one of several techniques for managing product development, under the broad
category of Agile Software Development. Agile methodology is designed to
support iterative and flexiblemethods for running a product.
Among the diverse agile methodology, Scrum is well defined for the types of organizations that
develop products such as software, websites and Information Technology tools. Scrum
encourages a team to work in a focused way for limited period of time on a definite amount of
work. It also allows the team to build and improve ability to estimate how much effort it will take to
develop a new feature and the lesson learnt are documented in a system.

Scrum Origin
At the time, the most suitable approach for software development was the Waterfall Model.
Under the waterfall model, product development happens in stages- Design, Implementation,
and Release.
In the late 1990s, the electronic media and the Internet emerged. To support these, software
development organizations had to incorporate more flexibility to adapt to changing variety of
platforms with different requirements. Soon after that, the development of large software
applications that lived on desktop computers gave way to smaller, more flexible apps that were
delivered through mobile devices. An identical approach was needed for developing these.
Scrum came into picture to work together in a sustainable and productive way, instead of waiting
until the entire cycle has completed.
Scrum - The Hottest Project Methodologies
Acquiring the knowledge of a new language is one of the initial steps in acquiring a new skill and
consistent use of language is fundamental to team trying to work together. There are a few terms
defined in the Scrum to understand its meaning clearly, they are:
Agile: It is a set of software development practices designed to help developers work together
and adapt to changes quickly and easily.
Customer: Whoever has engaged the team to create a product.
Developer: A person responsible for creating and maintaining the product.
Product Backlog: A constantly evolving list of potential features or changes for a project.
Product Owner: A person who helps define the product for the team.
Scrum Master: A person responsible for maintaining the artifacts and overseeing the rituals of
scrum.
Sprint: A fixed number of days during which the team can work together to produce an agreed
upon set of changes to the product.
Story: A clear and consistent way of dividing, phrasing, and discussing work the team may need
to do on the product.
Fail Fast Technique
Scrum wants you to fail. In fact, it's known for the slogan "fail fast". No, I'm not joking. It sounds
weird, but there is a very good reason for this. Traditionally, project managers and developers
would work for months or years before seeing the results. Most of the time, around 80% in fact,
the software and projects failed. So, why, you might ask, are they signing up for more failure?
Well, really, they are not.
The trick is in focusing on the second word: Fast. Failure is okay as long as you are learning from
it, but if you have to wait too long, you are not going to learn nearly as much from it. Scrum takes
the Agile manifesto and its key principles boils them down to a very simple framework that
encourages small-scale focus and rapid learning cycles.
Traditional Approach of Development
Traditionally, Waterfall project teams face three constraints: Time, Cost, and Scope. They were
unable to change any of these things once their project started.
The problem is, during the course of a project, the business environment changes around you.
This means, by the time you are done, what you built is no longer valuable. This isn't anyone's
fault. Business needs are changing more rapidly than ever. Project requirements are shifting just
as quickly to keep up.
In the traditional approach, first the client requirements are documented in details, architecture of
the software is planned and conceptualised and then the work starts to produce the end product.

Solve Project Problems with Scrum

Teams were doomed to failure on every project until the Agile manifesto came along. Then we
shifted our focus away from constraining all three project's elements, and decided to make one of
them flexible.
Agile is a broad umbrella of many methodologies that follow the same principles. Scrum is one
of them. Scrum took it a step further by creating a framework to help teams stay focus and
protect them from distractions. Essential to Scrum are two key roles, the Product Owner and the
Scrum Master.
In Scrum Framework, the client is constantly involved during the course of development,
reviewing bits and pieces created, time and over. The cost of testing a product is less when it is
being tested in parts separately. It is easier to test and produces more robust product.
Agile Principles
Waterfall as a methodology, is not a bad thing. In few cases it makes good sense, like to start
building construction, where a defined set of steps, when implemented in order, will result in a
building.
Factual work is more like a science experiment. You try something, check out the outputs and if
it didn't work for you, try some other approach. You surely can't do that when constructing a
house, but with software or some other product, you can do it every day. That's why waterfall
didn't work well for software development.
You literally cannot upfront plan the process of discovery. The frustration of highly skilled
software developers working on Waterfall projects was the tipping point that led to the Agile
revolution.
Have a look at the Agile Manifesto and it's underlying principles. This group of innovators
supported this manifesto with 12 key principles. This manifesto and the principles became the
foundation for a new set of project management and software development methodologies.
Agile Manifesto: Check Out
Principles behind the Agile Manifesto: 12 sacred principles
What make Agile different?
There are a couple of overriding themes that make Agile different. One of the key changes is
that, we're asking our business partners to work with us throughout the project. Not just show up
at the beginning to describe what they want, then show up at the end and tell us how we missed
the mark. We need direct, on going interaction to deliver what they really need.
Another key is that we no longer want to measure success using milestones and project phases.

Roles of Scrum Team

Scrum is a lightweight framework that can be incredibly flexible, efficient, and powerful, but,
much like a vehicle, the best body and designed frame will get you nothing without a powerful
engine to move you forward. There are two main important roles that exist on every Scrum team:
the Product Owner(PO) and the Scrum Master(SM).

Product Owner(PO)
The PO is the business representative of the team. They're not part-time team members. They
show up every day, because they're contributing to the final product every day.
They review all the work the team completes and either accepts it or asks the team to make
changes to ensure the highest value is being delivered. Earlier, the business person was
presented through requirements documents that were rarely, if ever, updated.
On a Scrum team, the PO is always ordering the work and ensuring that the team members
clearly understand the details of the request, but that's only one part of their job. They're also
interacting on a daily basis with the stakeholders.
It's not enough for the PO to interact with the team, they must also be in tune with all the
changes that are occurring in the business context. As a result, the PO is the keeper of the
product vision. He or she defines and manages the backlog of work to be done and the
prioritization of those work items.

Scrum Master
The Scrum Master is the most visible spokesperson for the team. Scrum Masters value
transparency. They'll devise charts and boards to share the team's progress with anyone who's
curious or interested in knowing how they're doing.
They're also the first escalation point when something gets in the way for the team. The Scrum
Master will work to remove any blockers until they're out of the way and the team can continue
on. While the Product Owner keep eyes on what needs to be done, the Scrum Master focuses on
how the team does the work.
One more thing, The Scrum Master also holds the team accountable for their commitments to the
Product Owner. They show trends in team performance over time to help the team improve their
processes and practices. As you can see, each role is absolutely critical to getting the framework
to function properly. If you're lacking one of these roles, Scrum will be far less effective than if
you have them both.
Build Your Scrum Team
Scrum is all about daily collaboration and communication. You should do absolutely anything to
make that easier for your team, as this will reap big profits down the line. That's why, if it's
possible, co-locate your team members in the same room, aisle or space to make that
collaboration more effective.
In many companies that's simply not possible due to building or distance barriers. That's okay.
You can still be successful with scrum. You'll just have to work a bit harder to ensure sufficient
collaboration takes place. Some things you can try are: Video conferencing, dedicated chat
rooms and conferencing phones at all your locations. These can easily help your team stay in
touch.
Now, let's talk a bit about the team composition. Your first priority must be to ensure that you
have a dedicated team with you.

Resources required to build a strong Scrum Team

If your team members are multi-talking between your project and another one, they lose a lot of
efficiency and that slows down your delivery.
Dedicating your core team to a single task, results in better focus, higher efficiency and faster
delivery.
1. Number of Team Members

As per Scrum guidelines, the ideal team size is seven members, plus or minus two. I know
this sounds specific, but research indicates these numbers maximize people's ability to
create close relationships and collaborate most effectively.

2. Communication Channel

Most of the time it is not possible to gather the team at one place for Scrum meetings and
other work related issues. In such situations, Communication Channel plays vital role to
collect team at one place. It may be a video conferencing or audio conferencing, just to share
your current progress and discuss road blocks, if any.

If you take the time to work through these elements and help your team set the stage, success
can come quickly for them. You will be astonished at how fast your team learn to work effectively
once you have set them up for success.

Set Vision For your Project

Vision is the map/outline/blueprint, that will show path to you and your team towards the
ultimate goal. The product owner establishes this before any work begins.
The vision of a project tells you, your team, everyone really, where you're going and what
valuable product or enhancement you'll deliver at the end.
The destination contained within the vision is what we call a Minimum Viable Product,
or MVP.
The MVP is about developing a product just enough to get it out the door to early adopters.
Who can then provide feedback for product improvment. This approach is basically saying,
that if we do a small set of work to get our usable product out the door, we've met the goal.
There are a couple of good reasons for approaching the work this way.
The first level of decomposition or the initial step in setting a project vision is to identify your
themes. Themes are just a broad grouping of similar work. So, carefully group the similar
tasks.

Real world example to understand Vision and Theme

Restaurants do this every day. Appetizers, Salads, Entrees, and Dessert are the themes they
work with. These aren't simply to attract or help customers read the menu. They're also useful
in organizing the kitchen. The same is true for your themes.
Considering an example of a Mobile App for customers to order lunch, our app themes might
be: profile, order, payment, and delivery, among others.
These themes help us in two ways. First, they help trigger ideas about what needs to be
developed to meet the MVP for that theme. Second, they help us group our work together so
we can be efficient and minimize risk, like ensuring we have security built before we
complete the profile development.
Once we've identified our themes, we break them down further into features. Features are
the next smaller slice of work we can use to help us stay organized. For example: a good
Profile has a user picture, details. Hence you would, require a feature of user uploading their
pictures and their other details, to be displayed on their Profile.

Writing User Stories

We've talked about themes and features as groupings of work. These are really useful constructs
to help us get organized but they're still too big for a team to work on and deliver value in small
timeframes. The user story then is the tactical level of work that can be delivered quickly. At the
same time, they're not so small that they deliver no value.
Anyone on the team can write user stories but it's usually the PO. As the stakeholder and
representative for the customer it's their duty to ensure everything in the backlog adds value for
the customer so they usually write the user stories.

Points to remember while creating User Stories

1. Good user stories are independent

First, good user stories are independent. It can be delivered separately from other stories and
have value by itself. If you only have time to do one thing, this story can stand-alone.

2. Negotiable

User Stories are also negotiable. Until the story is committed for work, it can be rewritten,
changed, or cancelled at any time. User stories must be valuable. It delivers value to the PO,
stakeholders, and customers.

3. Meaningful

User stories should be meaningful and it should deliver value to work.

4. Estimable

You must be able to estimate the size of the story in story points. That means that the story is
descriptive enough so you know what has to be done to finish it. Only then can you
understand the effort required.

A Story is a task, with all the details about the task mentioned in the story description. The story
is then assigned a time(story points), within which it must be finished. It is also given a priority,
important tasks can be marked high priority to be worked upon first.
There are many softwares available these days, for complete Scrum Planning like Jira by
Atlassian.
Writing good user stories can be challenging but if the requirements and planning is good, it gets
easier with time.
Throughout the agile lifecycle, your stories evolves. Large stories can be split to smaller stories, if
the single task is large to be implemented in a single iteration.
Multpile stories are clubbed under one Epic. When we say, at times, a big story can be
disintegrated to multiple small stories, we group all the small stories under one Epic. It is like one
big story.

Set Threshold for Success

Your next step is to create boundaries that your team can use to complete this work.
Each story has its own acceptance criteria, means when the story is marked as Done. This
definition of done, states the minimum requirements for all stories. For a story on our team to be
considered done, it has to be well tested in the pre-release environment or how about for a story
on our team to be considered done, it has been code reviewed and all errors fixed.
These acceptance criteria can be set while planning the scrum or by the Product Owner.
Next, your Product owner needs to be prioritizing the backlog. This is known as Backlog
Grooming. It simply means that the stories are continually sequenced in value order. The more
valuable the outcome of the story, the higher its priority is in the backlog.
Finally, you need to establish your Sprint Duration. Scrum says that your sprint can be
anywhere from one to four weeks in length, with a preference toward the shorter time scale.

Stories and Estimation in Scrum

There are two kinds of estimation. There's actual estimating and relative estimating. Actual
estimating is what you use when reading a map. It's 25 miles from Point A to Point B. This is very
specific. Then, there's relative estimating, which is comparing things to each other to get a
general idea of something. Like this cake is the same width as that pie.
In scrum, we use both kinds of estimating. We use relative estimation to get a rough size of our
work by comparing user stories to each other. This gives us an overall sense or estimate of how
big something is.
Stories themselves are rough guides to how the user wants to interact with our product. Because
it's a rough statement of need, we can't be too specific on how big it is. Also, since this is just a
rough cut, we don't want stakeholders to think we know precisely what it's going to take to get
that done.
Story points are the unit of measure we use to convey the relative sizes. Estimation is meant to
be lightweight and fast. It shouldn't take days or even hours to determine how much effort you'll
put into something. While it might take a little bit of practice, once you get the hang of it, you'll fly
through it.

A Real Life Example for Understanding

Let us take an example where we have to develop a website similar to Studytonight, with some
basic features. How we will plan and divide the work:

1. First, the Product Owner will be provided with all the reuired information. Information
about the project is generally provided by the customer, if it is an out sourced project, and if it
is a product of the company itself then, the Product Architect designs the requirements and
provides to Product Owner.
2. Once all the requirements are clear, which in our example are:
 o A Home Page with information about website
o A Profile Page
o Login/Signup Mechanism
o etc...

3. In this case, creating Profile Page and Login/Singup Mechanisms will be Epics, as

this will involve a lot of small sub tasks to be completed. Whereas, creating Home Page can
be one story.
4. When we say Login/Singup Mechanisms is an Epic, we mean, it consists of stories like:
o Defining Data Models(creating Tables) for Data objects, like User table to save

user data etc.

o Creating the User Interface(forms in HTML) for Login and Signup
o Then completing the backend for the Login/Signup system
o Integration Testing the system developed. This is very important in Scrum, that

you test, whatever small part you have built.

5. All the stories created are assigned Story Points, as in the time required to complete that
tasks. This is dependant on the following criterias:
o The amount of work to be done
o The complexity of the work
o Risk or uncertainity involved in the work

6. Story Points are measure of time. Mostly the Fibonacci series numbers are used for
story points. It can be 1, 2, 3, 5, 8, 13 and so on, where 1 means the task requires one
complete working day's effort.
7. Planning Poker is an activity created around the Scrum Planning to make this more

interactive. You can easily google how to play planning poker, or visit this Link
8. Hence scrum famework is nothing but what we may already be doing without knowing it.
It is one the perfect ways to plan and execute within a time frame to produce best results.
And yes, they have specific terms for everything.

Create a Roadmap for your Project

Scrum has a tool for roadmap and release planning as well. We use two different mechanisms
for the roadmap and the release plan. The roadmap is very high level and is intended to apply
over your themes over time. This way everyone has a general sense of what the focus will be on,
in a given time frame.
If we take an example of creating a Mobile app for food delivery service, there are so many
components we have to take care of. From order placement to payment and delivery tracking, we
need to decide the best order to work on this. So we will start from App design and order
placement system, later on we will move to payment system which is a third party integration and
most important feature of any business. Like everything else in Scrum this is a guideline not a
rule.
The roadmap is considered to be updated at the end of every sprint. The team will be learning
things and writing new stories throughout the sprint. So the roadmap is meant to be a meaningful
document. It's just a guide, but it's a guide that will help you stay focused on getting the project
done.

Release Plans
Once you've completed this you can organize your stories around the theme timelines you've
created. This is how you create your release plan.
The release plan is the next layer of detail. It's a high level plan that's meant to connect the
roadmap to the sprints. It provides visibility to how we're going to deliver.
In Scrum you must have fully functional stories completed at the end of every Sprint. You're not,
however, required to release them to the stakeholders at the end of every sprint. This means you
can complete all the work for two or three sprints before releasing the combined results together.
You'll use your story points to help your team decide what they can do within each sprint. Once
your team has been together for a while they'll reach what's known as a stabilized velocity.
What is a Scrum Sprint?
A Sprint is a time frame, not more than one month, during which a project or sub-project is
completed. Most commonly a sprint is of 2 or 3 weeks time. After completion of one sprint, the
next sprint starts immediately.
During the Sprint planning, stories, epics are created and during an ongoing sprint, no changes
are made, that may affect the sprint goal.
Every sprint starts with a Sprint Planning Session and at the end of every spring, a Sprint
Review Meeting is condcuted where the Product Owner reviews whether the commited tasks
are completed. Also, a Retrospective Meeting can be conducted to look back at the issues
faced during the last sprint, to improve upon those in the coming sprint.

Sprint Preplanning
The main agenda of Sprint Planning is to make sprint execution more effective.
To provide right preconditions, one need to take following actions during the sprint preplanning:

 Clarify the Acceptance Criteria. The criteria, that a story must qualify to be marked as
"Done".
 Provide the estimate of the user stories, to help Product Owner to identify the priorities in
the backlog.
 Break down high priority User Stories into chunks that will fit for a sprint.
 Consider dependency on the key resources in the team and workload for each team.
Managing Dependencies
A good user story is independent, it does not have any dependency.
There are 3 types of dependencies:

 Simple Dependency
 External Dependency
 Intertwined Dependency

Simple Dependency
Simple dependencies happen when one user story depends on another one. One way to remove
this unidirectional dependency is to combine or split the user stories differently. When this is not
possible, the alternative is to set a higher priority for the standalone user stories with the greatest
number of dependencies than their dependents.
External Dependency
External dependencies occur when a story is dependent on outside teams. In this case, the
teams need to negotiate integration and delivery dates and adjust the priorities of the stories. The
team working on the dependent story should not commit to completing the dependent story
within a Sprint until the other team delivers their user story.
Intertwined Dependency
These dependencies are when two or more user stories are co-dependent, and each cannot
complete without the other. Ideally, the team should look for ways to break all the connections or
look for ways to turn the intertwined dependencies into simple dependencies instead. Dealing
with these dependencies across Scrum Teams is a critical responsibility of the PO(Product
Owner) working with the Scrum Teams.
Product Owners and the Scrum development team need to focus their attention on the high
priority stories for the current release. That's why Sprint Preplanning is an important step for
effective Sprint planning.

Preparation for the Actual Sprint Planning

Adequate Sprint Planning is actually done by all the team members. It is not reasonable for the
team representative to commit the work across the team.
Key Points for Sprint Planning

 Team representative should prepare the sprint planning.

 If multiple scrum teams are working on same product backlog, they must gather and take
part in the sprint planning together.

Using the prioritized backlog, the PO presents the highest value stories to the team in order. The
purpose is that everyone on the team fully understands the intent of the story and specific
acceptance criteria for that story. It is also helpful to explain the definition of done for all the user
stories.
Every sprint starts with a Sprint Planning Session, which includes two sessions - the WHAT-
meetingand the HOW-meeting. In the WHAT-meeting the team picks the User stories from the
Scrum backlog, on which they will be working. And, in the HOW-meeting, the User stories picked
are further broken into small tasks with a set priority and story points.

First Half of Planning - Deciding What to achieve

Reviewing Sprint Goal
Scrum meeting representative will show the high level vision of the project. The Product Owner
identifies the goal of the Sprint and justify that how it will deliver value to the product.
Reviewing the Product Backlog
Before the sprint planning meeting Product owner will rearrange the user stories and give the
priority to the stories.
During Sprint Planning, PO presents the highest-priority user stories to the team. Stakeholders
will give feedback on the user stories. Stories may change on the basis of stakeholder feedback.

Second Half of planning - How to get work done

During the second half of the planning, team decide how to get work done.
Creating Backlog
PO reviews the highest priority stories with team and decides how much they can do in each
sprint. Everyone should commit his or her work in this planning. If someone can't commit, the PO
and team need to work together to change the shape of the sprint until everyone can commit.
Sprint planning is a key collaborative effort in scrum.
Updating the Release Plan
Once the team has committed to user stories, the Product Owner revisits the Release Plan
mapping of user stories into Sprints. With the current information, stories that the team
completed in the previous Sprint, stories taken off the Product Backlog for the current Sprint, the
Product Owner updates the release plan.
Scrum takes the commitment step very seriously. Each person's commitment is very important to
achieve your sprint goal. Starts from reviewing sprint goals to updating the release plans, each
step must be should followed carefully.
Tracking Scrum Progress
If the project is critical, it is pretty common for your stakeholders to ask the team that how things
are going on. This is good as people are invested in the outcome of project. But it can be a
distraction for team if only some team members have the full perspective on how things are
going.
Scrum addresses these challenges by posting Information Radiators. An information radiator is
anything that you post on team sites that help everyone understand what you're doing and how
it's going. It is a good practice to follow this approach to let stakeholder know what's going on in
the project. It shows the stories committed to in the sprint, the tasks and their current status, and
what tasks have been completed.
Another primary tool for sharing information on your progress is the sprint Burn Down Chart.
The team, to measure how well they're executing the sprint, uses this chart. Where the task
board tells you about task completion, it doesn't tell you how that compares to where you are in
the sprint. A burn down does that.

Burn Down Chart

A typical burn down chart starts with a straight diagonal line from the top left to the bottom right,
showing a burn down rate for the sprint. Lines or columns on the burn down chart may be used
to represent the number of points of effort actually remaining in the sprint from day-to-day,
starting with the work that team has committed to at the sprint planning. As work is completed,
these columns should become shorter until they reach zero.
Below you will find a very simple Burn Down Chart:
The straight green line here, represents the ideal burn down rate. With each passing day of the
sprint, efforts are put in to complete all the tasks.
The orange line with circles, represent the actual burn down. When the actual burndown is above
the Idea burn down line, means that the team will miss the date for completion, and needs to add
more people to increase the velocity.

15 Minutes of Daily Stand-up Meeting/Daily

Scrum
The Scrum Master will establish your daily scrum. This is also commonly referred to as the daily
standup meeting, or standup, for short. In order for scrum to work, it relies on the three C's:

 Collaboration
 Communication
 Cadence

The standup includes all three. It is the foundational element of collaboration as it includes
everyone on the team: the developers, the testers, the product owner, and scrum master.
It occurs at the same time every day, so your scrum master will select a time for the standup that
works for everyone. For teams that are co-located or within a few timezones, this is pretty
straightforward. For international teams, this can be a bit more challenging. But with today's
video conferencing capabilities, this is achievable as well. The bottom line is that daily standup is
one of the non-negotiable of the scrum framework. This is the time when tasks are moved across
the board.
At the same time, your standup is not a progress report. No one should be delivering the full
explanation of his or her activities, just the overview. Stakeholders are also encouraged to
attend, but ask them to hold their questions and comments until the end of the scrum.
Daily scrum is short. It's limited to 15 minutes. It can be shorter, but it cannot be longer. The
whole team stands to keep it fast, thus the shorthand name, standup. The scrum master also
limits updates to three questions per person: What did you do yesterday?, What are you going to
do today?, and Is anything blocking your progress? As individuals go through these questions,
the whole team understands their progress as a unit and see how their work fits into the whole.

Backlogs in Scrum
In Scrum methodology, term Backlog is a prioritized list that contains short description of the
functionality required in the project.
The stakeholders want to ensure they get what they need from your project. A key aspect to
keeping the right priorities throughout the project is the on-going refinement of the product
backlog. This means that the PO is out there meeting with stakeholders to understand what's
needed. They're constantly moving the work around as the business needs and requirements
shift.
Throughout the project, your backlog is constantly changing as new features and stories are
being found and added. Other stories are being changed and maybe even removed.
As new stories are discovered, the Product Owner works out the details and acceptance criteria
for each one. But at least once per sprint, the whole team must come together to see what new
items have come up. This is usually a 30 to 60 minute Backlog Grooming Session. It usually
happens around the midpoint of the sprint. The Product Owner reads the new stories to the
team, and the team asks about any details that are missing.

Responsibility of Product Owner over Backlog

1. Respond to team on new stories, if they require any clarifications.

2. Set the priority of the backlogs.
3. Allow the Scrum team to adapt to the changing business needs throughout the life of the
project.
4. Interaction with team in mid of the sprint.
5. Fill the gaps in the requirements without any delay.

The Product Owner for the scrum team is like the driver for a vehicle. For the verhicle to run
smoothly and complete its journey, the driver must work well and provide anything that the
vehicle requires, be it fuel or repair.

Get Stories Done in Sprint

In Scrum, the team takes their sprint commitment very seriously. They're striving each day to
collaborate and get their stories to done.
Remember, in Scrum, done means usable product that meets the acceptance criteria. Since
that's the goal, the team is developing and testing the entire time, to ensure the entire story
Acceptance Criteria is met.
The Acceptance Criteria approval though, has to come from the product owner. Since the
product owner is the business representative on the team, their acceptance or rejection is the
final word.

There are four key elements of successful execution of Sprint:

 Daily Planning
 Daily Collaboration
 Focus and Done
 Measurement

Daily Planning
Discuss everyday with your Scrum master and plan your day together. Take up a new fresh story
and start working on that. As the story completes, pass on the workflow to respective testing
team and plan for new task.

Daily Collaboration
Collaborate with your team and Product owner and understand the definition of done for each
story on which you are working on. Collaboration is required to get the team progress on the
current sprint.

Focus and Done

The easiest way to stay focused on Done is by showing your work to the customer frequently.
You need this on-going feedback to ensure that when you think something is done, everyone
else thinks so too.

Measurement
Measurement is another way to execute successful sprint. Track your progress on burndown
chart everyday.
As the team completes the tasks, the Scrum Master keeps track of what was done and uses the
Burndown Chart to show the team whether they're on track to complete their commitment for the
sprint.
The most commonly tracked Agile measure is Velocity. This is simply the number of points a
team completes from their backlog each sprint.
The team acknowledges their progress and keeps their eye on what's coming. This collaboration
helps the team maintain awareness of the whole project. It keeps the team focused on the big
picture while delivering a usable product in every sprint.

Demo the Team's Work

In Scrum, we strive to deliver a working product at the end of every sprint. But what's the point if
no one knows about it? Scrum's answer to this is the Demo.
As you know, the PO is accountable for accepting or rejecting what's been delivered. Whatever
they accept is ready to be demonstrated to a larger audience. Remember, the PO is accountable
to the other stakeholders as their representative to ensure they get what they want.
This is the difference between Traditional Waterfall Design and Agile's Scrum Methodology.
In waterfall, once the project is completed, we get to know the stakeholder's feedback but in
agile, at the end of every sprint, demo is required to get the feedback from the stakeholder.
The demo is how the PO and team make sure the stakeholders are happy with what we're
delivering. The demo is a powerful ceremony for Scrum teams. The demo builds trust between
the team and the stakeholders. It's a great opportunity for the team to receive direct feedback.
The stakeholders get to see for themselves the work being done on their behalf. They provide
feedback to the team, both praise for what's been done, and suggestions for changes, also
known as new stories. The PO will capture these and after the demo, set about adding details
and setting the new stories for their backlog. Sometimes, the stakeholders will see something
that's demonstrated and decide they don't want it after all. That's completely okay.
Another advantage of the demo is to let the stakeholders know who is working on their project.
They get to see for themselves the skills and dedication each team member brings to every
sprint. This is an opportunity to build relationships between the team and stakeholders. This
visibility gives the stakeholders a broader, more balanced perspective on what it takes to create
their product.
Additionally, the stakeholders will see the team's willingness to receive feedback and adapt to
their changing needs. Finally, the demo shows the overall progress toward the final goal. Your
PO will keep your product road map and release plan up to date after every sprint. This is where
you show them to your stakeholders. Your team is bringing the stakeholders along on the journey
with them. The stakeholders can also provide feedback on the timing and contents of each
planned release.
Note: Be sure you demo regularly to keep your product and stakeholders in close alignment.

Evaluate your Team

For a scrum team, 100% of every sprint is focused on the needs of the stakeholders and the end
users, but the principles behind agile say that teams need to reflect regularly on how to be more
effective and adjust their behaviours accordingly.
In scrum, this principle has taken shape as the Team Retrospective, or Retro for short. This is
the one time every sprint when the focus is not on the product, it's on the team itself.
Since the focus is on the team and team processes, the Scrum master facilitates this ceremony.
In order to have a successful retro, you must have a safe environment. As a result, this is a
closed-door session. The team must know that only dedicated team members will be present and
that the team norms will be observed. This sense of safety is essential to ensuring the open
dialogue that's needed to honestly assess the way the team is working together.
Usually the agenda for the retro is simple. It consists of three questions. What worked
well?, What did not work well? and What will we improve?
While everything on this list is important, be sure to start with the Team's successes first. I know
this sounds backwards. We're here to get better, why focus on what we already do well? But in
order to help the team stay away from responding defensively, you need to appreciate them first.
Fill their emotional bank accounts before you start sharing the improvement areas. When you
focus on question one, pay attention to everything the team did well that's within their control.
This includes:

 Examples of great collaboration both inside and outside the team.

 Recognize things the team has done to help each other out.
 Be sure to full focus on the team itself, not the stories they have completed.

By focusing on success, the team creates a positive behaviour loop.

They'll want to become better so they have more to celebrate the next time. When moving to
question two, what didn't go well, be sure to focus on things that you can change, not on outside
groups or tools that are beyond your control. For example, perhaps your team needs to use a
specific testing tool and the tool is slow. Your improvement area wouldn't be to fix the tool, it
would be to find a better way to use the tool more effectively.
All the other tools scrum teams use are about the product. The retro is powerful because it's
about the team itself. Remember, scrum is a framework that can only be successful when the
team is healthy and focusing on improving themselves as well as their product.

Spotting the Sign of Trouble

Just like traditional projects, scrum projects can also run into trouble every now and then. Here
are some Scrum specific techniques to look for potential trouble with your project:

 Missing the Target: Consistently check that the work completed matches the plan, and
you do not have any leftover features added to the product backlog at the end of the sprint.
This is known as Snow Ploughing. This is similar to the end of the first and start of the
second sprint when you are revising estimates to match team productivity. However, if this
continues to happen at the end of each sprint, you must gather the team to discuss and
understand why this is happening, and take appropriate action.
 Miscommunication leads to Wrong Product: Another notable indicator of a problem is
when the team frequently produce pieces of a feature and throws them away. This could be
 due to the development of features that turn out to be a low priority, are not what was
required or are incorrect, or need to be revised based on receiving new information. Often the
primary reasons for these problems relate to the business representatives not asking the
right questions to understand the business problem. Or the customer doesn't understand
what you're trying to build, or you do not have accurate information about the real business
need.

If you believe these are possibilities, then you should conduct a product review with the customer
to understand the root cause of the problem.
Based on the customer's input during this review, you should revise the product backlog
appropriately.
Another focus item to avoid trouble is to carefully watch team attendance at meetings. Are all
your core team members present and participating in daily team meetings and follow up
activities? There could be valid reasons for the occasional mental or physical absence by an
individual, but repeated absences could be signs of a problem.
The last item to think through when looking for Scrum trouble spots is, are you the fixer of all the
problems you see? Successful Scrum teams are self-organized and self-governed. So you
should have confidence and must believe in your team members, and leave some space for the
self-governing to work. This means resisting the temptation to be the fixer all the time.
Agile approaches are powerful and deliver great outcomes. Careful monitoring of the common
trouble spots can help ensure you will deliver business values successfully.

Closing the Project

You are about to close the project, you must do this with full focus to understand and document
lessons learned for the entire project.
In the scrum terminology, this is called a retrospective. You can invite additional stakeholders to
the retrospective to look at the project seriously. Once the project retrospective is completed, you
can now start the final closeout for the project.
You have reached this point in the project based on the condition that all the required features
have been implemented.
As you have spent your time and funds on the project, you'll have a few extra things to consider
before closing down the project. You need to look into the backlog list and work with the business
to get the importance of the remaining features. In addition, you'll need to find out if there were
new features the business would like to have implemented.
If the set of backlog features are important and there are additional new features to be
considered, it's possible a new project is warranted if the funds can be acquired. If the backlog
contains lower priority features, it is likely a new project will not be initiated.
In this situation, the backlog needs to be transitioned to someone who can implement those
changes. Another approach the business may want to take is, let's wait and see. If the backlog is
important but they don't have a lot of new features at this time the business may want to wait
several months to determine if new features surface and a new project is warranted. Regardless,
it's very important for the backlog list to be given back to the business so they can maintain the
list until future decisions are made.
You can focus on the overall effectiveness of the project, versus all the details that occurred
since the beginning of the project, and can reflect on the improvements you have made, as
individuals, and for the business.