Sprint Plan:

In scrum, the sprint is a set period of time where all the work is done. However, before
you can leap into action you have to set up the sprint. You need to decide on how long
the time box is going to be, the sprint goal, and where you're going to start. The sprint
planning session kicks off the sprint by setting the agenda and focus. If done correctly, it
also creates an environment where the team is motivated, challenged, and can be
successful. Bad sprint plans can derail the team by setting unrealistic expectations.
 The What – The product owner describes the objective (or goal) of the sprint and
what backlog items contribute to that goal. The scrum team decides what can be
done in the coming sprint and what they will do during the sprint to make that
happen.
 The How – The development team plans the work necessary to deliver the sprint
goal. Ultimately, the resulting sprint plan is a negotiation between the
development team and product owner based on value and effort.
 The Who – You cannot do sprint planning without the product owner or the
development team. The product owner defines the goal based on the value that
they seek. The development team needs to understand how they can or cannot
deliver that goal. If either is missing from this event it makes planning the sprint
almost impossible.
 The Inputs – A great starting point for the sprint plan is the product backlog as it
provides a list of ‘stuff’ that could potentially be part of the current sprint. The
team should also look at the existing work done in the increment and have a view
to capacity.
 The Outputs – The most important outcome for the sprint planning meeting is
that the team can describe the goal of the sprint and how it will start working
toward that goal. This is made visible in the sprint backlog.

Sprint Backlog:

The sprint backlog is a list of tasks identified by the Scrum team to be completed during
the Scrum sprint. During the sprint planning meeting, the team selects some number of
product backlog items, usually in the form of user stories, and identifies the tasks
necessary to complete each user story. Most teams also estimate how many hours each
task will take someone on the team to complete.
It's critical that the team selects the items and size of the sprint backlog. Because they
are the people committing to completing the tasks, they must be the people to choose
what they are committing to during the Scrum sprint.

The sprint backlog is commonly maintained as a spreadsheet, but it is also possible to

USER STORY TASKS DAY 1 DAY 2 DAY 3 DAY 4 DAY

As a member, I can read profiles of other Code 8 4 8 0  

Design 16 12 10 4  
the…

Meet 8 16 16 11  
with
Mary
about…

Design 12 6 0 0  
the UI

Automat 4 4 1 0  
e test…
 USER STORY TASKS DAY 1 DAY 2 DAY 3 DAY 4 DAY

Code the 8 8 8 8  
other…

As a member, I can update my billing Update 6 6 4 0  

Design a 12 6 0 0  
solution
to…

Write a 8 8 4 0  
test plan

Automat 12 12 10 6  
e tests…

Code 8 8 8 4  
the…

During the Scrum sprint, team members are expected to update the sprint backlog as
new information is available, but minimally once per day. Many teams will do this during
the daily scrum. Once each day, the estimated work remaining in the sprint is calculated
and graphed by the ScrumMaster, resulting in a sprint burndown chart like this one.
The team does its best to pull the right amount of work into the Scrum sprint, but
sometimes too much or too little work is pulled in during planning. In this case, the team
needs to add or remove tasks.

Let's take an example using the sprint burndown chart above. As you can see, the team
in this scenario pulled in too much work initially into the sprint backlog, and still had
nearly 600 hours to go on day 13 of a 20-day sprint. The product owner was consulted
and agreed to remove some user stories from the sprint. This resulted in the big drop on
the chart between days 13 and 14. From there, the team made consistent progress and
finished the Scrum sprint successfully.