Scrum it's not a Fish it's a process.

Our Best Practice du jour is Scrum lightly sauteed served over a bed of TFS.





So Scrum isn't a fish, it's actually a very British term describing a disordered or confused situation involving a number of people. And this is a pretty accurate description of what Scrum looks and feels like when you first get started. But after some practice you will realize that Scrum is actually an elixir for itself, Scrum actually brings order and clarity into situations involving teams.

Scrum succeeds where other development methodologies fail because it is light weight yet rigid. Scrum defines a set of simple, common sense phases and ensures each phase is successful by declaring immutable laws for each phase.

Scrum is an Agile process that forces teams to continuously realign their projects to deliver a shipping product that has been enhanced with real business value in a pre-determined period of time. If you read this too fast it comes out sounding like a fancy way of saying they meet their estimated schedule, but the key is the word realign, the team realigns itself not to just meet the schedule but to meet the schedule with as much real business value as possible. And this is where Scrum gets very interesting for the non-technical business leaders.


In software development projects it's pretty common for features and functionality to be jettisoned in order to meet the schedule. The problem with most development projects is that the scope is defined by the release which can contain many features. The project gets loaded up with features at the start.


It's like ballast in the big old sail boats of long ago, sailors would load up the big boats with extra weight (usually rocks) to weigh down the boat in the water, this made it ride through the water at the optimal depth. The rocks for a development project are the features, and the optimal weight is what product owners perceive as real business value.



Ballast in the big old sail boats became a problem at the end of the journey, usually at the ports of call. The ports were generally shallow and required the ship to ride higher in the water or else get stuck on the bottom. So the ballast would be discarded to reduce the draft of the boat and enable it to sail in safely.


Right before a project docks for shipment it's usually obvious its riding too low in the water, it's going to bottom out before it makes it to port, so Ballast (features) is jettisoned, usually in no particular order, to reduce the projects draft so it can make it to port (shipment).

So how does SCRUM address this problem. Before the planning of a software project SCRUM dictates that the Product Owner creates a Product Backlog, a list of all the things the Product Owner feels are important to get into the product to increase the value proposition to the customer. These are called Product Backlog Items or PBI's. Before the planning meeting the Product Owner must rank these backlog items, ensuring those with the highest business value are done first.

The development team than assigns a weight (related to effort) to each PBI based on previous experience with similar items. After a certain total weight is achieved the Sprint is full. A Sprint is basically a development cycle post planning phase to shipment. Sprints are defined by a total weight, or level of effort that cannot exceed a certain short time period, usually 30 days. Not all PBI's in the backlog will make it into the Sprint. They may be deferred to following Sprints. And a large feature may be split across several Sprints.

The planning activity of generating PBI's and ranking them based on business value, and the selection of a set of PBI's to fill a Sprint, increases the success of the project or Sprint. What is basically happening is the Product Owner is very carefully selecting what ballast needs to go into the ship before it is launched, with the understanding that it won't be jettisoned before making port. It won't be jettisoned because the development team is carefully considering each PBI and weighting it based on previous experience and than only signing up for a Sprint's worth of weight, not a monolithic projects worth of weight. Margin of error is restricted to the Sprint and not multiplied by the number of Sprints it may take to complete a larger feature much less a shipping version.

It is also important to note that another immutable rule of Scrum is at the end of each Sprint the product must be in a shippable condition. So if a feature is being added that spans multiple Sprints the Product Owner has the flexibility of deciding whether to ship the partially completed feature, and wait on the remaining enhancements for a subsequent release. Or it may be that the PBI's for a feature that didn't make it in were not that important and the Product Owner is good with shipping what they have.

Once a set of PBI's are assigned to a Sprint the development team than reduces each PBI into Tasks. These tasks become the Sprint backlog, which is basically an execution plan for the development team. Eash task is assigned an estimate of effort by the developer who owns it. The percent completed is updated daily and reported at a daily meeting called a Scrum. This data also becomes available if you are using an environment like Microsoft's Team Foundation Server to produce burn down charts so everyone can see if the ship is going to make it into port.

In conclusion, I'll reiterate that Scrum succeeds where other development methodologies fail because it is light weight yet rigid. There aren't many of rules but the rules that are defined in Scrum make it a successful process on large or small projects. We have used Scrum successfully for more than 6 months now, across multiple product lines. It is a full contact development process with everyone at the table and engaged and aware.