“Scrum” is another formal project management/product development methodology and part of agile project management. Scrum is a term from rugby (scrimmage) that means a way of restarting a game. It’s like restarting the project efforts every X weeks. It’s based on the idea that you do not really know how to plan the whole project up front, so you start and build empirical data, and then re-plan and iterate from there.
Scrum uses sequential sprints for development. Sprints are like small project phases (ideally two to four weeks). The idea is to take one day to plan for what can be done now, then develop what was planned for, and demonstrate it at the end of the sprint. Scrum uses a short daily meeting of the development team to check what was done yesterday, what is planned for the next day, and what if anything is impeding the team members from accomplishing what they have committed to. At the end of the sprint, what has been demonstrated can then be tested, and the next sprint cycle starts.
Scrum methodology defines several major roles. They are:
- Product owners: essentially the business owner of the project who knows the industry, the market, the customers, and the business goals of the project. The product owner must be intimately involved with the Scrum process, especially the planning and the demonstration parts of the sprint.
- Scrum Master: somewhat like a project manager, but not exactly. The Scrum Master’s duties are essentially to remove barriers that impede the progress of the development team, teach the product owner how to maximize return on investment (ROI) in terms of development effort, facilitate creativity and empowerment of the team, improve the productivity of the team, improve engineering practices and tools, run daily standup meetings, track progress, and ensure the health of the team.
- Development team: self-organizing (light-touch leadership), empowered group; they participate in planning and estimating for each sprint, do the development, and demonstrate the results at the end of the sprint. It has been shown that the ideal size for a development team is 7 +/- 2. The development team can be broken into “teamlets” that “swarm” on user stories, which are created in the sprint planning session.
Typically, the way a product is developed is that there is a “front burner” (which has stories/tasks for the current sprint), a “back burner” (which has stories for the next sprint), and a “fridge” (which has stories for later, as well as process changes). One can look at a product as having been broken down like this: product -> features -> stories -> tasks.
Often effort estimations are done using “story points” (tiny = 1 SP, small = 2 SP, medium = 4 SP, large = 8 SP, big = 16+ SP, unknown = ? SP) Stories can be of various types. User stories are very common and are descriptions of what the user can do and what happens as a result of different actions from a given starting point. Other types of stories are from these areas: analysis, development, QA, documentation, installation, localization, and training.
Planning meetings for each sprint require participation by the product owner, the Scrum Master, and the development team. In the planning meeting, they set the goals for the upcoming sprint and select a subset of the product backlog (proposed stories) to work on. The development team decomposes stories to tasks and estimates them. The development team and product owner do final negotiations to determine the backlog for the following sprint.
The Scrum methodology uses metrics to help with future planning and tracking of progress; for example, “burn down” – the number of hours remaining in the sprint versus the time in days; “velocity” – essentially, the amount of effort the team expends. (After approximately three sprints with the same team, one can get a feel for what the team can do going forward.)
Some caveats about using Scrum methodology: 1) You need committed, mature developers; 2) You still need to do major requirements definition, some analysis, architecture definition, and definition of roles and terms up front or early; 3) You need commitment from the company and the product owner; and 4) It is best for products that require frequent new releases or updates, and less effective for large, totally new products that will not allow for frequent upgrades once they are released.
- 1615 reads
