I’m going to give a brief overview of an Agile development process called SCRUM. At the end of this article are some links to further information for those of you that want to read about SCRUM in more depth.
First some terminology:
- Scrum Master - The person who enables the Scrum process, a facilitator
- Product Owner - The person ultimately responsible for defining the product and its features
- Iteration - A set cycle of development time
- Sprint - Scrum name for the iteration cycle
- Development team - Everyone it takes to get from requirement to tested releasable code (coders, testers, Q&A, Analysts, DBA’s etc)
- Velocity - A measure of the completed features for a given iteration
The first thing you need to begin Scrum is a Product Backlog. This is essentially a list of features or in my case user stories. This initial list - just enough to get you started - should be prioritised by the Product Owner according to business priorities. Next you’ll need to decide on your iteration lengths. Typically a team starts with iteration lengths of 30 days but some teams prefer 2 week iterations.
Now you’re ready to begin Sprint planning. Sprint planning is usually split into 2 four hour section - during the initial phase of planning the Development Team sit with the Product Owner and the Scrum Master to estimate items on the Product Backlog. These should be sized according to their relative complexity - that is ‘how big is this feature?’ not ‘how long will it take?’ Points are awarded to each User Story. This meeting is usually time-boxed to around 4 hours with as many features as possible estimated in that time. Times for daily scrums and the end of Sprint Review and Sprint Retrospective are also agreed.
With the backlog estimated and prioritised the team work out how many of the most important items on the Product Backlog they think they can do in the allotted Iteration or Sprint period. This can be based on the teams current Velocity if the team have been sprinting together for a while or it can be based on the expert opinion of the team. Based on the items chosen from the Product Backlog a Sprint Goal is agreed with the Product Owner.
For the second half of Sprint Planning the team take the list of items to be worked on during the Sprint - the Sprint Backlog - and break down each item into more granular tasks covering everything from coding to meetings. These tasks are estimated in hours to complete. The team then commits to deliver the functionality in the Sprint Backlog along with the overall Sprint Goal.
Once the Sprint begins there are daily meetings of around 15 min where the team gets a chance to inspect and adapt again. Three key questions are asked: What have you done, what are you going to do and what has been an impediment to your work? It is then the Scrum Masters role to work with the business to remove those impediments to progress for the team.
Once the iteration comes to a close the larger inspect and adapt cycle kicks in. There is a Sprint Review with the product owner to go over all the code completed in that iteration. The Product Owner runs through the software to be sure it meets the original requirements and if it does the team are awarded the points for each user story deemed complete. These team points are their Velocity - a measure of the amount of functionality/complexity that they can deliver per iteration. This review period is also a chance for the team to share their work and get feedback from the rest of the company.
The best time for a Sprint Retrospective is right at the end of the iteration. During the retrospective the team looks at what went well and what didn’t and looks to adapt accordingly. Once the retrospective has been held its back to Sprint Planning and the iteration cycle kicks in again.
Some further reading.
Books:
Agile Project Management with Scrum
Agile software Developement with Scrum
Websites:
