I just read again the book of F. P. Brooks , “The Mythical Man-Month: Essays on Software Engineering”, and can’t avoid create relations between his thinking and Scrum, specifically with the development of the Sprints.
A sprint produces a visible, usable, deliverable product that implements one or more user interactions with the system. The key idea behind each sprint is to deliver valuable functionality.
Each product increment builds on previous increments. The goal is to complete tasks by the sprint’s delivery date. A sprint is time-boxed development, meaning that the end date for a sprint does not change.The team can reduce delivered functionality during the sprint, but the delivery date cannot change.
During the sprint, the team holds frequent (usually daily) Scrum meetings. These meetings address the observation made by Brooks: “How does a project get to be a year late? One day at a time.” When the team comes together for a short, daily meeting, any slip is immediately obvious to everyone. The meetings involve all team members, including those who telecommute. The meetings serve a team-building purpose and bring in even remote contributors, making them feel a part of the group and making their work visible to the rest of the team.
What happens during a Scrum meeting?
Each team member must answer three questions:
1. What have you completed, relative to the backlog, since the last Scrum meeting?
2. What obstacles got in your way of completing this work?
3.What specific things do you plan to accomplish, relative to the backlog, between now and the next Scrum meeting?
The Scrum meeting should last 15 to 30 minutes, which provides enough time to address obstacles, but does not allow time to brainstorm a solution. All discussion other than responses to the three questions is deferred to a later meeting involving only those actually affected by the discussion. The goals of the Scrum meeting include focusing the effort of developers on the backlog items, communicating the priorities of backlog items to team members, keeping everyone informed of team progress and obstacles, resolving obstacles as quickly as possible, tracking progress in delivering the backlog functionality, and addressing and minimizing project risk.
What happens at the end of a sprint?
At the end of a sprint, the team produces an increment that builds on previous increments. The team can trim functionality but must meet the promised delivery date. After each sprint, all project teams meet with all stakeholders, including high-level management, customers, and customer representatives. All new information from the sprint just completed is reported. At this meeting, anything can be changed. Work can be added, eliminated, or reprioritized.
Customer input shapes priority-setting activities. Items that are important to the customer have the highest priority.
New plans and estimates are made following the same process discussed under “How do you plan and estimate?” Assignments are then made to teams for the next sprint. As sprints finish, estimates become better as planners see what each team has produced in previous sprints. With the small time increments, the planners must be careful in their estimation, because, as Brooks states, “Extrapolation of times for the hundred-yard dash shows that a man can run a mile in less than three minutes.”. Because each sprint produces a visible, usable, increment, product delivery can take place after any sprint. In fact, delivery of a sort does take place and feedback from the business and marketing side and from customers is a reaction to the current increment’s delivery. Typically, final delivery takes place after a wrap-up phase that is run as a final sprint.
The organization can make one very important decision at the end of a sprint: whether to continue product development. Given what was delivered during the last sprint and the current state of the market, the stakeholder meeting should address the question, “Should this project continue?”. This is a business decision and must be made after considering all the technical and marketing issues.
As a result of the interaction of small teams in small, focused development cycles, the product becomes a series of manageable chunks, progress is made, even when requirements are not stable, everything is visible to everyone, team communication improves, the team shares successes along the way and at the end, customers see on-time delivery of increments, customers obtain frequent feedback on how the product actually works, a relationship with the customer develops, trust builds, and knowledge grows, and a culture is created where everyone expects the project to succeed.
See u