The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
Posted by admin under Scrum Basics
There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. In my last two articles, I discussed the roles and responsibilities of the Product Owner and the ScrumMaster. Now I’ll discuss the team and its function in Scrum.
In Scrum, an ideal team would include seven members, plus or minus two. Usually, teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. It is recommended all team members be located in the same room, called the team room.
While the development team must complete the work negotiated in the Sprint Planning Meeting, the team has some say in the amount of work it takes on. The Product Owner will expect the team to take on as many story points of work as possible, within reason. (The team would reference its established velocity for previous sprints to negotiate how many story points would be reasonable.) The value of this process of negotiation is twofold. It protects the development team from becoming swamped with an unrealistic workload. It also manages the expectations of the Product Owner, who, in turn, can do the same for customers.
Similarly, the team has the autonomy to determine how and when to complete its work. As long as the team finishes its work by the deadline and under budget, it is entirely up to the team to determine how that happens. Theoretically, the team could crank out all of its work in the first half of the sprint and spend the second half lounging at the beach, as long as the work satisfies the corresponding acceptance criteria. Granted, a team typically needs the entire sprint to complete its work. Actually, it’s not unusual for teams to discover within the first few days of a sprint, as analysis becomes less fuzzy, that it has more work to do than it realized at the sprint planning meeting. Furthermore, Scrum does not award partial credit. Even if 99 percent of a project is “done,” it will be rejected if it does not meet all the established acceptance criteria. A project’s finishing touches are often the most time-consuming and labor-intensive.
Teams are responsible to inspect and adapt their process in the Sprint Retrospective Meeting. Here is what Scrum looks like from a developer’s perspective:
posted by: scrum methodology
Leave a Reply
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013