I have been programming since the time I was 12. I started writing code to play a text based role playing game called MajorMud. The Mud community called it ‘scripting’ and boy was it controversial, not to mention, a character being played by a script made a very easy target if you were into PVP.

While I spent countless hours making my script smart enough to survive jealous player’s attacks or how to handle an onslaught of zombies I realized that coding would, from here on out be a part of my life.

I got my Computer Science degree and when I joined the corporate world, my company was just getting into Agile development. As part of this we started implementing SCRUM and I was introduced to a new way of coding that changed my life forever. Ok.. well not really, but it did fundamentally change the way I coded software. No longer would I blindly code 100 lines and ‘hope’ I got it right. I faced the cognitive dissonance that the way I learned and was taught in school was the only way.. I saw a better way and have not looked back sense.

Test Driven Development is a fundamental shift in the way you should write code. It is not just for Production code.. no! even when I am writing prototype or just for fun code, a test is the start.

So what is test driven development really you may ask?

A definition that I prefer is:

    TDD = Test First Development +  Refactoring

The scope of TDD that I am talking about in this blog is really around unit tests. To do this, you need to have some kind of automated unit testing framework. The most famous are JUnit, NUnit and CppUnit depending on your coding language.

How do you do it? It is simple:

•     Write the test, run the test (it should fail)
•     Write the code to make the test pass
•     Move on to the next test
•     Refactor & Repeat

Some additional rules I like to follow:

•     No Non-Test code is written unless a test is failing.
•     Do the simplest thing you can think of to make the test pass then move on!

For a real time example, check out this video I made:
http://www.youtube.com/watch?v=LsPIjyFpSKk

I go through an exercise where I create a Palindrome checker! A very simple example but it gives you a crash course on how TDD works.

TDD is much easier when you are starting on a fresh project. It can be a challenge if you are dealing with a legacy code base but it can be done (Yes I have done it!).

I have also personally seen how test driven development has increased quality in my own coding and in the various teams I have been involved with.

TDD all the WAY!

Posted By Brian Lawrence.

At this point we have seen how to:

• Estimate the Product Backlog
• Plan a Sprint
• Monitor a Sprint
• Have a Sprint Retrospective

The sprint is now over, the team has finished it’s tasks, it is time for the Sprint Review

Demo what is done

The main purpose of a Sprint Review is to provide the team the opportunity to demonstrate what was completed during the sprint. It is all about demonstrating working software that is done.

In theory done means shippable to your customer, in reality depending on what type of project or company you work for, done may have different meanings. For example if you work on a very large project, done may translate to being able to get your component working on the system testing environment while for our example, done is having the 2nd floor walls up with a roof over our head.

Sprint Review Logistics

The entire world is invited, this includes the team, the product owner, and any other customers or stake holders. One to two hours is generally enough, the meeting should not exceed 4 hours.

The sprint review starts with the Scrum Master providing some context and any numbers about how the sprint went. The entire team is then encouraged to participate and show the software they have created. This includes explaining the user stories or flows of what is going to be demonstrated then the actual demonstrations themselves. The majority of the time in the Sprint review should be the demonstrations. If the team has performed a sprint retrospective, some output from that can also be mentioned once the demonstrations are finished. 

A sprint review is supposed to be informal. The stakeholders are permitted and expected to ask questions so the team can get feedback and has the power to change something if needed in the next sprint. This is one way the team can make sure the customer gets what they want instead of what the team thinks they want. This is a good way for the stakeholders to see how well their expectations were clearly explained to the team without finding out at the end of a release when there is no longer any time to make a change.

See the video here on SsZ.tv.

Posted by Brian Lawrence.

This article examines 3 different ways to monitor how a sprint is progressing.

These are:

• Burndown
• Cardwall
• Mid-Sprint checkpoint.

Burn Down

The burn down is a graphical representation of how the team is progressing during the Sprint.  It compares work remaining verses time left.  The Y-Axis represents the work-remaining in hours, while the X-axis represents the time.

The ideal burn-down rate is the perfect rate a team would burn. It is often shown on the graph to be used as a comparison to provide a better understanding on whether or not the team is on track.

There are several tools which can be used to generate a burn down chart. A Spreadsheet application such as Microsoft Excel or Open Office Calc can be used; software is also available which will generate a burn down.

Card Wall

The card wall provides an easy way to quickly determine how the team is progressing. The card wall is typically in the team room and team members are encouraged to move the cards as they pick up sprint tasks. There are typically columns to show state of each sprint backlog item such as Not Started, In Progress, and Complete.

During sprint planning team members can create each task while they task out backlog items. That will save the scrum master some time.

The card wall is simply a communication tool that has been proven to work well. Electronic versions of card walls do exist and are available but I have found that the traditional card wall makes the work a little more tangible and is normally within a quick glance of the team members.

Mid-Sprint Checkpoint

The mid-sprint checkpoint is simply a pulse check. If the burn down or the card wall shows that it does not appear the team is on track for completing all of their sprint goals, the mid-sprint checkpoint provides the opportunity to address that.

The value of this checkpoint approach comes into play for Sprints that are longer term, for example a 4 week or monthly sprint.

If the team is not on track it is, this is where options are looked at for getting back on track. This could mean coming up with a plan to make a slice ‘thinner’, (still try to have something deliverable but maybe not have so many bells and whistles). A quick meeting could be called after the daily scrum / standup to spend 15 minutes brainstorming on ways the team can get back on track.

Mid-Sprint checkpoints are not typically part of the agile ceremonies however I have found it has been useful in the past. This may also be more useful on newly formed teams. Teams that have been together for a longer time typically will do this on a daily basis and most likely will not need this.

See the video version of this at SsZ.tv.

Posted by Brian Lawrence.

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.

The ART of -ing

If you are not familiar with SCRUM, here is the wikipedia definition: SCRUM is an iterative, incremental framework for agile software development.

The focus of this short is the estimation aspect of a product backlog. For additional information about SCRUM, perform a Google or Youtube search. There are many sites and videos that will provide an overview in a small amount of time.

What is a WAG?

If your from the UK you might think this is an acronym for girlfriends or wife of famous football players (soccer), in software development terms however a WAG is an acronym for Wild @$$ Guess.

Estimation Techniques:

Table Top T-Shirt Sizing (S,M,L,XL)

Each backlog item is written on a 3x5 index card and placed on a table.

• Identify the smallest sized item to act as the point of reference (S).
• Group each card, with each corresponding group approximately twice as large as the first. (M = S+S, L = M+M)
• Any item larger than XL is an epic which is too large to estimate.
  (These need to be re-evaluated and broken down into an estimatable size)

Once all items (cards) are placed into their groups. Points are assigned to each size.

Fibonacci numbers can be used or simply double, for example:

Double: S = 1, M = 2, L = 4, XL = 8
Fibonacci: S = 1, M = 3, L = 8, XL = 13

Planning Poker

• Each backlog item is discussed with the participating team members.
• Each participant has a planning poker card deck.
• Once the product backlog item has been discussed, everyone shows their card..
• If the estimates are close together, the higher of the estimate is taken.
• If there are large gaps between estimates then the highest and lowest discuss with each other out loud why they think their estimate is more accurate.

For distributed teams, there is software available that will allow this exercise to take place. For example: PlanningPoker.com

Velocity

In physics velocity is the rate of change of position.

In Scrum, velocity is how much product backlog effort a team can handle in one sprint.

Example: Product Backlog of 1000 Points. The team has burned 300 points in three sprints. The velocity is 100 points per sprint. (300/3 = 100)

At the current velocity this team would project it would finish the remaining 700 points in 7 sprints.

See the video here on SsZ.tv.

The word Retrospective comes from the Latin word retrospectare meaning “look back”.

If you are familiar with the term “Lessons Learned” then retrospectives may seem very familiar.

There are several types of retrospectives:

• event retrospectives (how did an event go)
• project retrospectives- scope is entire project (several months to a year)
• sprint retrospectives (focus of this short)

Sprint Retrospectives have become a core principle in the agile SCRUM world. These are performed in an effort to continuously improve. (the Inspect & Adapt process in agile)

Sprint Retrospective Logistics:

The meeting is typically an hour in length but not longer than 3 hours.

Only the team should attend, no managers or product owners. This is for the team.

Pigs Only!                          No Chickens..

Facilitation is often handled by the Scrum Master however this is not a rule. You may find that having a team member facilitate is a good way to keep the retrospectives fresh while at the same time giving other teams the opportunity to practice some facilitation.

Retrospectives should occur at the end of every sprint.

Goal of the Retrospective:

The focus of the retrospective is to look back at:

1. What went well?
2. What did not go well and needs improvement?

At the end of the meeting you should come up with 2 to 3 actionable items that you can realistically look at getting done in the next sprint. 

Retrospective techniques:

Card form – Hand out 3x5 cards/stickies- can be colored, green/red and blue for action items

• 20 minutes filling out cards for what went well
• 20 Minutes filling out what needs to be improved
• When finished hand up to facilitator to place the cards on the wall or table (group by topic)
• Remaining time going through each topic and deciding on actionable items.
• Works well in larger groups / newly formed groups / shy groups

Free form - Overhead projector and or flip chart / white board
Team calls out answers, while facilitator records

• 20 minutes focusing on what went well
• 20 minutes focusing on what needs to be improved
• Remaining time discussing actionable items
• Works well in a very open and tight-knit team where everyone is comfortable speaking their mind

There are other flavors but I find these two approaches are Simple and work (KISS!). Do what works for your team.. The key is getting participation and finding valuable action items so your team can adapt.

Look for trends – Keep the results of the retrospective and every 3-6 months look back.. do you see the same problems, do you see trends, are the action items being completed ? Same problems or new?

See the video here on SsZ.tv.