Monday, December 25, 2017

What is a Sprint in Scrum? | Supreme Agile

תוצאת תמונה עבור ‪scrum sprint‬‏
According to the Scrum methodology, development cycles are called " Iterations" and with the other and more familiar nickname of "Sprints". These development cycles are relatively short and can go anywhere from a week to a month (Most organizations iteration with a length of two weeks).

During each development cycle, the team collaborates as a single unit to deliver a working part of the software based on the customer demands and expectations. At the end of each sprint, the team will present the accomplished work (A.K.A: User Stories) and right after that review a new iteration that based on new tasks can start.

What is the idea behind this short development cycles?

The answer is simple when the team needs to take commitment to a long-term task they will not be able to see when it ends. Now, in most cases, the team will provide an Eta, but the problem remains the same, the team does not have the ability to take real commitment because no one can foresee the problems, challenges and new tasks that can arise during this time that will reduce the focus from the main task.

To resolve these problems, scrum uses short iterations that are restricted in time and in the number of tasks that the team will perform which will allow them to remain focused on short-term tasks without the need to foresee the future work month ahead. 

In addition to the above, we can see some other great advantages for using the method of short development cycles:

  • There is more room for handling issues that arise during the iteration.
  • The team will determine the amount of work that they will do per iteration, this sense of ownership will help to increase their sense of commitment. 
  • The team will commit to only the amount of work that they can deliver. 
  • The team will use a set of structured meetings: Daily Scrum that will allow them to remain focused on the iteration main goal, Planning meeting that occurs at the start of the sprint to understand the requirements, challenges, and expectations prior to taking any commitments that based on the team capacity and velocity, Retrospectives to improve and adapt the process for maximum efficiency, and review meeting that will allow them to get real feedback about the quality of their work.

The Main Phases of a Sprint 

Phase 1: Determine the Sprint Backlog and Team Commitments

Every sprint begins with a planning meeting (Pre-Planning meeting may be also used), which involve the entire scrum team, during the meeting the team discuss which user stories should be added to the sprint backlog, the decision is made based on the prioritization of the items in the product backlog (PO) and the team velocity that determines the amount of work that the team can handle in a single iteration.

The sprint backlog is a set of stories that should be delivered by the team at the end of the sprint, each story that is added to this backlog should be approved by the team prior to taking any commitment to deliver it.At the end of this phase, we have prioritized sprint backlog, updated product backlog, known goals, and set of commitments made by the team.

Phase 2: Sprint Execution

The team will work together to finish their commitments for succeeding to meet the iteration goal. Their work will include different activities such as Design (HLD/LLD), Coding (TDD/Continues integration Etc.) and testing (Risk Based testing/Exploratory and Automated testing on different layers of the code (Unit, Component, Integration, and System)).

In addition, this phase also includes the daily scrum meeting that will help the team to synchronize about the remaining work and to ensure that everyone stays in focus regarding the iteration goal. 

Phase 3: Iteration Results

Once the iteration is completed (2-4 weeks), the team will demonstrate the potentially shippable product increment to the relevant stakeholders (Product Owner, Customer, Etc.).

Phase 4: Continuous Improvement

At last, the team also performs a retrospective meeting at the end of every sprint to discuss on how things went and what can be improved in future sprints.    

1 comment:

  1. This method although practised in companies is not a sensible approach of software development. This is because the shape that comes in the initial releases out of this practice is a crap. This can be seen in the first few releases of almost every software. Just because, the team has given a date to deliver, they deliver which is not a workable product but just a piece of crap.


My Presentations