IT

Definitions:

• The sprint backlog: it's created on the first day of a sprint during the sprint planning meeting by the team members. It can be thought of as the team’s to-do list for the sprint. Whereas a product backlog is a list of features to be built (often written in the form of user stories), the sprint backlog is the list of tasks the team needs to perform in order to deliver the functionality they committed to deliver during the sprint.During the Sprint the ScrumMaster maintains the sprint backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done. The estimated work remaining in the sprint is calculated daily and graphed, resulting in a sprint burndown chart.
  Example of a sprint backlog:

• Two other primary artifacts are the sprint burndown chart and release burndown chart. Burndown charts show the amount of work remaining either in a sprint or a release. They are a very effective tool for determining at a glance whether a sprint or release is on schedule to have all planned work finished by the desired date.
  The graph below exemplifies a sprint burndown chart: the team does its best to pull the right amount of work into the sprint but sometimes too much or too little work is pulled in during the Sprint planning meeting. In this case the team needs to add or remove tasks. In the above sprint burndown chart you can see that the team had pulled in too much work initially and still had nearly 600 hours to go on 5/16/02. In this case the Product Owner was consulted and it was agreed to remove some work from the sprint, which resulted in the big drop on the chart between 5/16/02 (619 hours) and 5/17/02. From there the team made good consistent progress and finished the sprint successfully.

Main Roles on a Scrum team:

• The ScrumMaster: is the team’s coach and helps team members achieve their highest level of performance. A ScrumMaster differs from a traditional project manager in many key ways, including that the ScrumMaster does not provide day-to-day direction to the team and does not assign tasks to individuals. A good ScrumMaster shelters the team from outside distractions, allowing team members to focus maniacally during the sprint on the goal they have selected.
• The product owner: While the ScrumMaster focuses on helping the team be the best that it can be, the product owner works to direct the team at the right goal. The product owner does this by creating a compelling vision of the product and then conveying that vision to the team through the product backlog. The product owner is responsible for ensuring that the product backlog remains prioritized as more is learned about the system being built, its users, the team, and so on.
• The team itself: Although individuals on a Scrum team may come to that team with various job titles, while on the team those titles are insignificant. Each person contributes in whatever ways they best can to complete the work of each sprint. This does not mean that a tester will be expected to rearchitect the system; individuals will spend most (and sometimes all) of their time working in whatever discipline they worked before adopting Scrum. But on a Scrum team, individuals are expected to work beyond their preferred disciplines whenever doing so would be for the good of the team.

Main Activities on a Scrum Project:

• Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held during which the product owner prioritizes the product backlog, and the scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to the sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint. During the sprint planning meeting the product owner describes the highest priority features to the team. The team asks enough questions during this meeting so that they can go off after the meeting and determine which tasks they will move from the product backlog to the sprint backlog. After the sprint planning meeting, the Scrum team meets separately to discuss what they heard and decide how much they can commit to during the coming sprint. In some cases there will be negotiation with the product owner but it will always be up to the team to determine how much they can commit to completing.
• Sprint review meeting: At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal way; for example, PowerPoint slides are not allowed. The meeting must not become a task in itself nor a distraction from the process.During the sprint review the project is assessed against the sprint goal determined during theSprint planning meeting. Ideally the team has completed each product backlog item brought into the sprint, but it is more important that they achieve the overall goal of the sprint.
• Daily scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum. The daily scrum is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum. During the daily scrum each team member provides answers to the following three questions:
     1. What did you do yesterday?
     2. What will you do today?
     3. Are there any impediments in your way?

Strenghts of Scrum

• concentrates on deliverables (vs. process): it changes the way teams behave and, in fact, makes them behave like teams. It allows team members to make explicit decisions on what the do and do not spend their time on, in light of the team's self-created goal of delivering some set of user stories to production.
• from the management or product management perspective scrum provides a clean and easy to communicate set of priorities, prompting an honest and open discussion of what the team should actually be working on. It give stakeholders a simple and understandable way to affect the priorities of the team and gives perfect (but not lasting) visibility into what will get delivered.
• getting the team to become single-minded about delivering user stories to production helps bring focus and measurably to the development process. The scrum master can also have a positive influence by rejecting distractions and non essential tasks and activities, further boosting productivity. An approach with great focus on the relationship between the business and the development team: others methodologies also emphasizes a good collaboration between the team and the customer. But here, the Product Owner is so important, it's really a first class citizen of the methodology. The Product Owner owns the vision and the direction where the team should go. Not only at the beginning of the project or where the team ask questions, but sprint after sprint.
     - It encourages focus by making you constantly prioritize. The top priorities always get dealt with, as the whole process is geared up to focus only on the priorities. This process makes it all very transparent;
     - It allows you to always have something you can test and get feedback on: lower cost of making a change. That's a winner in both the eyes of the business and developers;
• It encourages discipline by making you constantly finish and evaluate what you do;
• A "no trauma" methodology with few mandatory practices easy to understand and room for improvement: We all know that Scrum contains only few basic things to implement: roles, backlogs, sprints, planning meeting, daily standups, demo and retrospective. That's it. It's not enough because we also need collaboration and engineering practices. We need effective ways to build up backlogs, perform retrospectives, etc... But we may discover, improve or change them along the way. We can start small, take the time we need to get our own pace and style. We're not stuck in a "30 mandatory practices or forget" kind of thing. In short, Scrum is gentle with people who want to go that way.
• It gives you a great chance to motivate talented people by providing them with autonomy;

• Scrum teams have a high degree of autonomy in determining how to best execute to their goals, how to organize, and how to adapt their process;
• Scrum teams demonstrate mastery on a regular basis by successfully delivering working user stories to production and by having concrete measures for success;
• Scrum teams have a clear purpose that is agreed upon by everyone involved in the transparent process of setting and changing priorities. They also tend to phrase their goals in terms of things that are directly useful to real customers;

User stories