While there are variations to implementing scrum, these are the generally accepted best practices for Unwired Logic.

Sprint Zero

Sprint zero doesn’t have a fixed amount of time applicable for all projects – each project is unique so the length of sprint zero varies.

During the kickoff some time should be allotted to discussing what is needed in the sprint zero and to determine how long it should be.  Essentially the first few hours should be spent discussing the definition of ready – what do we need to start this project?

Standard items that should be discussed in sprint zero are:

• Architecture & design– while a valid exercise – it is important to have this discussion to “get it out of our systems” and then chuck it so we don’t get locked in;
• Team training – try and identify skill gaps early on and plan for necessary training;
• Product vision should be crafted during the sprint zero and disseminated as early as possible;
• Setting up technical environment should be largely completed during sprint zero. This should include the development, testing, staging and live environments.  If possible, deployment tools needed to move the product from environment to environment completed here;
• Definition of done debated and finalized;
• Initial story workshop – stories or themes created and planned out per the release planning strategy. Stories that will be happening in early sprints should be fleshed out in more detail;
• Minimum viable solution required to launch and an initial release plan created.

Release Planning

This is the exercise of defining the minimum viable solution – or what experience we want to deliver to the customer.  This experience or vision is the glue for the release and all the stories should support that vision.  This will determine the minimum set of functions required for the release and answer the question “when will we be done?”

It is important to note that without team velocity release planning is difficult.

Sprint Planning

At the beginning of every project the product owner needs to describe his/ her vision to the team.  This will be the inspiration to the team in developing the product.  In addition to the product vision, vision must be updated or explained – as needed – for specific sprints or releases.

The product owner will present the vision along with any high value/ high risk stories.  The team will take that vision and stories and start to decompose the stories into tasks.  Tasks are estimated in hours.

The team will also conduct capacity planning and commit to the amount of work in the sprint.

Story Writing

The structure of a story

• Title
• As a <user> I can/ want <action> so that <result>

Scrum focuses on results and a working product and cares less about how we get there.  Stories follow a similar approach – focus on the experience that you want to deliver with the story not the features.  To do this – we need to understand the persona of the customer – really understand what that specific customer needs to do.

Eventually stories are broken into tasks.

Cheats and hacks

If a story has already been completed but you forgot something – you can simply attach it to an unrelated story as a task.  Alternatively, since we have a “no bug” policy we can treat forgotten items as a bug.

Tasks

Tasks are typically part of a decomposed story and estimated in hours.  However, there are times where something has to be completed but doesn’t fit into a specific story.  It is ok to create a task and work on it in a sprint.  However, it isn’t tracked as part of velocity – technical debt is likely a better term.

Spikes

Spikes are time boxes discussions that are for future stories.  These need to be discussed far in advance of the sprint where the story is planned.  Never do a spike in the same sprint where the story is happening – that is trying to build the plane while it is flying.

The goal or purpose of the spike is to ensure that we have discussed the story enough in advance so that when it comes time to build the story everything has been discussed.  It is common to create 2 spikes for a single story if we have a few options to discuss. 

Estimating

Estimating story size in story points will feed into the release planning so we understand when we will likely attempt to build a specific story and to understand when we will be completed.  We can use t-shirt sizes XS to XXXL to visualize this or leverage Fibonacci numbers directly.

Planning poker is used and all members must agree on the size before the story is considered estimated.

It is important to note that points are relative sizing and don’t correspond to hours.  We will use a modified version of Fibonacci 1, 2, 3, 5, 8, 13, 20, 40, 60, 100.  The goal is to group similar size items together rather than a precise estimate. 

You have to take 3 different aspects when estimating: Complexity, Effort & Doubt. 

Complexity is the stuff we need to figure out.  We know we can solve it – we just have to figure exactly what we want to do. 

Effort is the amount of work that needs to be conducted.  You may know how to do it but it may take time to complete the work.

Doubt are the items that we don’t know if we can do it or not.  Could be we are looking in the wrong area for a solution or don’t think the technology is up to it.

Consider all 3 when estimating.

Prototyping

Throw away work is highly encouraged in scrum.  It is easier to build something the second time and by creating something that everyone can touch – you get better concrete feedback.

Grooming

Typically conducted mid-sprint and should take between 1 to 3 hours.  Grooming is used to talk about upcoming stories and ensure a common understanding within the team.  The definition of ready is used to guide items that need to be completed.

Definition of Done

The DoD requires different things to be completed at different levels during the project.  The task level is the most detailed but each step builds on the previous DoD.

Bugs

Bugs are not allowed to exist at the end of a sprint.  If a bug is discovered, we stop what we are doing and fix it right away.

Retrospectives

The retrospective is a time for the team to reflect and ultimately improve on their methods and teamwork.  It is important that a plan for the retrospective is created and verbalized during each and every retrospective – it is important for all to understand why we are here and what we are trying to accomplish.

The retrospective should be fun and interactive so that people want to be there and participate constructively. 

Retrospectives are a chance for everyone to list out what we like, don’t like and a chance to rant.  Create 3 columns on a white board for each section and each person must write down 5 to 10 items and put them in a column.  Each person gets 3 votes – write initials on 3 stickies’ that you think are most important to prioritize them.  Talk about the items with the most votes first.

If the retrospectives aren’t useful or people aren’t putting up the real issues – then we have team trust issues.  Remind everyone that this is a safe environment and that we have been working together for the last 8 to 10 years.  We see each other more than our friends and family. 

Standard goals are:

• Pair programming
• Test driven development
• Time tracking

Technical Debt

Technical debt is defined as technical issues that we want to solve but haven’t yet.  A good example is legacy code.  If we have certain items we want to catch up on such as performance, UX or operations we can run a catch up sprint – similar to sprint zero.