Scrum for the busy project manager or business stakeholder
If you have no idea of what Scrum is and you’re too busy to follow a seminar on the subject, this is a quick summary for you.
The essence of Scrum is time-boxed iterations officially called sprints. It may be 2 weeks-length but it’s up to you depending on your type of project and organization. At the end of a sprint a workable demo should be delivered during a Review meeting where business users will be able to test and give feedback. This demo is not a throwable piece of software but a part of the final software with partial functionalities – concept of incremental and iterative development or IID.
In the spirit of Agile, Interaction between people are keys so that Business People and Development Team should be in constant involvement with each other. There is no product or project manager but a product owner and a scrummaster (in corporate organization he may be a former project manager or a lead developer). The product owner will drive the business requirements through a list of desired features called user stories which will be accumulated in a product backlog. The scrummaster will then be able to pick up some stories towards the sprint backlog during a sprint planning meeting – which occurs at the beginning of each sprint. The selection of the stories will depend on the priorities given by the product owner. Team members will then list the tasks derived from the sprint stories and put them on a task board. The taskboard is divided into vertical lanes like “to do”, “in progress”, “test”, “done” (or one could use Deming’s PDCA – plan do check act/correct).
The motto of Scrum – in fact of Agile – is transparency and courage so everyday, team members will attend a daily standup meeting (about 15 minutes) where each one will assess the progress of the sprint (expose the status of his tasks, the impediments encountered and his tasks plan for the day by updating the task board,…) and of the whole scrum implementation itself through retrospectives. Scrum also prepare a burndown chart which supposedly reflects the number of work done substracted from the whole number of works necessary for all iterations to make a release – so to speak release planning which is the theorical base for comparison to actual. Numbers are counted in relative points or in periods – named story points. Each point is relative from team to team and take as reference a simple task (for example creating a dialog box). These points are estimated during the sprint planning meeting by all the team members often using a technique called poker planning.
This is as quick summary as possible but of course following a course is best.