This solution short provides a basic overview of Sprint planning.

What is a Sprint?

A sprint is an iteration or period of time of development that is focused on certain goals.

The length of the sprint is up to the team or in some cases your organization will define how long it is to keep the teams on the same schedule. Two or four weeks is the typical.

At the end of the sprint, ideally you will have something your customer could see and use. Something could be considered customer shippable. This will allow quick feedback so if what you delivered is not what your customer wanted, you will know!

What are the prerequisites to doing sprint planning:

• New to have a product backlog that is estimated.

• The Length of the sprint needs to be defined.

• You have a team and you know how many hours your team can put into the Sprint.

One way to do sprint planning is to do a two stage approach.

1. Pre-Planning

2. Planning

Sprint Pre-planning Meeting

The meeting consists of the product owner and the team (analysts, testers, developers, scrum master).

The objective is to identify the product backlog items you want to target getting complete during the sprint.Once you have identified the product items that are being targetted, each item is assigned to developers and/or analysts.

After the meeting is over, the developers/analysts who have been assigned an item must derive the Acceptance Criteria, Deliverable and Customer (ACDC) of each item. Once they have identified the ACDC, they are to task out each backlog item. Tasking out is the breaking down of a backlog item into smaller hourly tasks. Each hourly task should range from a minimum of 2 hours to a maximum of 16.

Once everything is tasked out in hours, we can determine what the team will be able to target within reason during the sprint based on capacity.

Sprint Backlog

This example is from a job I have been doing with my friend John. We are upgrading his single story garage into a 2 story garage/man cave. This is an example of 2 weeks worth of work (A 2 week Sprint).

Note: This shows that the idea behind Sprinting can also be used outside of software development!

Lay Deck Floors: 2 team members x 12 hrs = 24 hrs
Concrete Slab work: 2 team members x 3 hrs = 6 hrs

Total = 30 hrs

Framing of 2nd floor
Cut 2 team members x 4 hrs = 8 hrs
Construct 3 team members x 6 hrs = 18hrs

Framing of Rafters:
Cut 2 team members x 4 hrs = 8 hrs
Construct 3 team members x 12 hrs = 36 hrs

Total = 70 hrs

Sheath Roof 3 team members x 6 hrs = 18 hrs
Windows 3 team members x 6 hrs = 18 hrs

Total = 36 hrs

Total Backlog Hours = 136 hrs

Sprint Capacity

For the example we will define 1 days worth of work to be equal to about 6 hours worth of capacity.

We can then determine how much capacity the entire team has based on the availability of the team members.

Brian = 3 days = 18 hrs
John = 8 days = 48 hrs
Jeff = 3 days = 18 hrs
Dale = 6 days = 36 hrs

Team Capacity =120 hrs

As a team it is up to you to commit to a backlog that is greater than your capacity.

For teams that have not been together very long, it is recommended that you do not over commit.

In the case of this example if we remove the last item of windows which was 18 hrs then our total backlog is 118 hours. That is a reasonable number to target for the Sprint.

Teams that have been together for longer will have history on their side. In theory, a well oiled team may not even need to go to this hourly level, they could use their velocity to determine how much they want to commit within a sprint however theory is often far different from reality! (To my dismay, I love theory!!!)

Sprint Planning Meeting

The meeting consists of the the customer (stakeholders), the product owner and the team (analysts, testers, developers, scrum master).

Pre-planning is finished, all the backlog items have been tasked out. At this point our estimate for the targeted items went from the high-level WAG estimate to a more detailed (and hopefully more accurate) granular hourly level. We now have an understanding of how much we can commit to.

During this meeting we clearly define the Sprint goals. It is recommended that these goals are something that if sent to the customer could be used. The term “Vertical Slice” is often used which in a nutshell means something that can be demonstrated or used (in software → From UI to DB and back again).

The team will then agree to “commit” and they are officially off to produce that product!

See the video here on SsZ.tv.