Tuesday, July 24, 2007

Beginner's guide to Scrum

Its almost 2 month, since I promise to post more about scrum methodology. Never got chance to write on this till date. None the less, here goes begginers guide

Scrum is yet another s/w methodology which focus more on interaction and colloboration amongs team. Here team doesnt simply mean group of developer/tester and architect but also project manager and business stack holders (or atleast some representatives of them).

Before we can proceed any further here is introduction of few terms
  • User Stories: mini card which describe feature of application, give it a name.
  • Product Backlog: List of all user stories which together implies functionality required by our application, listed in decending order of priority.
  • Sprint: Development Iteration, typically 1-3 weeks time. At the end of which development team comes up with demo of what has been implemented.
  • Sprint Backlog: Document which includes top priority stories out of product catelog which needs to be implemented in next/current sprint.
  • Story Points: Measure used for estimating size of user story.
  • Velocity: Number of story points that can be implemented by given team in single sprint.
  • Focus Factor: Fraction of Idle time, development team is expected to spent on implementation of current sprint backlog items.
  • Burndown chart: Pictorial representation of how many story points have been left, at any point of time during sprint.
With this knowledge lets move forward and state how they fit into day to day work.
At the very begining of project business stack holders, project manger and developers(part of the team if full team is not in place yet) come to user strory writting workshop. Input point for this workshop is user expection from the user and outcome is product backlog. While its true that end user know this part better, its important to involve developer as well since they are the one who comes up with non-funcitonal requirements during this workshop. (i.e. security and performance requirement).

Well if that sounds like requirement gathering phase of Waterfall method, wait a minute. Best part here is, this backlog is not static read only document. It just guides team to the right path. Depending upon visiblity and upcoming ideas during sprint, stack holders can come up with new features, droping certain part and product manger will readjust backlog iteam based on know priority at that point of time.

Once this gourd work is in place development team's work is very straightforward. Decide sprint duration and velocity (Initiate with trail and error method, adjust it until team is comfortable with it).

Now is time for sprint planning meeting.

Attendees for this meeting are stack holders, project manger and development team (by the way development team also includes testing people). Team starts by taking first item of product backlog, clarify what is the scope of this story, estimate it in terms of story points and putting it in current sprint backlog. This process contines till sprint backlog is populated with items whose estimation sums up to agreed velocity for this sprint.) Original story can be further segregated into multiple stories in this planning meeting as well as two or more stories can be combined to one. Nothing is hard and fast here. Flexibility is everywhere:). One important piece of information against each story is "step to demostrate". Together team indetify step to demostrate completion of that story.

With sprint backlog in place, developers task is to grab one story and start implementing till all the stories are done.(Developer can always pick up phone and dial to business owner should there be any doubt during implementation of any story and story can even be changed at this point if that makes sense to business). At the end of sprint, team meets again and performs those agreed upon steps to verify completion of user story. Any finding at this point will be included in product backlog and again starts game of planning next sprint. This game continues till business owners are satisfied with the system or they run out of budget to develop any further.

What are the benefits fo this approch???? Well there are many but someof them I would like to point out are
  • High degree of flexibility and adoptability is clear visible benefits.
  • Making sure that team works on high priority features always.
  • Highly recommend for development project where end user can't envise full set of functionality at the very begining.
  • Continues feedback by user rather than waiting till end which enables early correction.
  • Cost of changing is low and doesn't increase exponetioally with project duration.
  • Continueous collobaration between stack holder/user and developer ensures end product which meets user requiement.