Yo ....

What I state here are my views / opinions / whatever you like to call them ... it has nothing to do with my employer or the ferocious man-eating bow-bow's that chased me one morning when I attempted to jog trying to stay fit in Chennai.

Saturday, September 5, 2009

Scrum it ....

I have been meaning to do some reading on SCRUM and make some notes on "How to implement SCRUM in a project in a simple manner?" ... and finally got a chance to do it today ... here are some notes that people may find useful ....

To create a product we need a something known as a product backlog. A product backlog is like a wish list that several people have for a product.

We gather all these features and create a master backlog that is planned under several releases.

But first we need the “Product Owner”….this person owns the product and decides what goes in or what does not go into the product.

Then there is the “scrum master”, the role of the scrum master is to ensure that all the team members have the right tools, facilities etc to create the product and this is the person who conducts meetings to understand where the team stands etc.

Key Roles in Scrum are
• Developers
• Testers
• Customers
• Executives
• Scrum Master
• Product Owner
• SME’s (subject matter experts)

First phase
Create a product Backlog…this should contain the entire set of features that we want to create.

From the Product Backlog, we create the release backlog … this is a subset features planned for each release….

From the release back log we then prioritise each feature and estimate the time required to deliver them … By deliver we mean a proper working version of them.

No matter what happens some SME’s have to be there during estimation phase and to help the testers test.

Now…the Release backlog is broken down into sprints…There must be at-least 4 sprints minimum in a Release … can be more.

Important aspect of each sprint is that at the end of each sprint an end user must be able to use the product piece that is delivered.

Very important to make sure that a sprint is not delayed, and the only way to measure the delay of a sprint is using something known as a “Burn down chart” ….

Burn down chart shows the current status and also the velocity of closure information, ie, the speed at which tasks are getting done. Burn down charts also help in estimating projected completion date based on the velocity.

Burn down chart basically tracks the completion of granular tasks within a sprint on a daily basis.

So take for example a Sprint “X”….

If there are 5 tasks in a sprint each taking various durations to complete … measured in hours…on a daily basis the completion of these tasks are recorded using the developers/testers status’s.

Obviously we have the question of how do we handle bugs? … no software can exist without bugs….bugs must be dealt with within each sprint…. Also we can have additional sprints specifically for killing bugs and call it “bug killer sprints”…
Bugs are tracked in SCRUM and are known as “Defect Backlog”

A feature cannot be closed without all the bugs being closed.

One important thing in SCRUM is to have daily stand up meetings, in these meetings people should stand as these meetings are not supposed t last long….some of the questions that are supposed to be asked in these meetings and answered are …
What are you doing today?
What is your defect backlog like?
What are the things you plan to do to recover from them?
Do you foresee any risks or problems that we need to handle?

Its not mandatory to conduct these meetings daily in a closely knit team that is mature but it is important to have them once in a while.