Introduction To SCRUM Framework

WHAT IS SCRUM

1. Scrum as a lightweight framework that utilizes principles and practices that assist teams in delivering working software in short cycles to the customer enabling rapid feedback continuous improvement and quick response to change

2. It promotes delivering value as in working software to the customer in an incremental and iterative way

3. It is not a process or technique for developing software rather it is a framework within which various processes techniques and practices are employed in scrum

4. The iterations that deliver working software to the customer are called sprints. In each iteration or sprint results in potentially shippable software.

  SCRUM FRAMEWORK

Product Owner And Product Backlog :-

1. The product owner owns the product backlog and in collaboration with the team develops the user stories or requirements for the project

2. The product backlog is prioritized with the higher priority items occupying the top of the product backlog in collaboration with the product owner the team decides how to group the user stories into releases based on the product roadmap once the release planning has been completed

5. The user stories are then selected for a sprint the duration of the sprint is going to be two to four weeks once the sprint backlog has been determined the team then disaggregates each user story into tasks


What is Sprint Planning :-

1. During each sprint the user stories are developed as the code is written it is integrated into the system and daily scrums are held at the end of a sprint there is a sprint review where the working software is demonstrated and presented to the customer for acceptance the team then conducts a spring retrospective.

2. During the retrospective the team looks at primarily three things

-> What went well
-> What did not go well
-> What should be done differently

3. Going forward the team's velocity is then updated as are the information radiators which transparently display the status and progress of the project and then the cycle repeats itself until the project is complete.

4. A sprint is an iteration in scrum at the beginning of a project the scrum team determines the duration of Sprint's for the project most Sprint's are going to be two to four weeks in duration factors affecting sprint duration include the stability of the product backlog

5. Once a sprint has begun the duration is never changed nor are any user stories added or removed therefore if many changes are expected a shorter sprint duration would be best however if the product backlog is relatively stable a longer sprint duration may be appropriate overhead there are overhead costs associated with each sprint for example every spent is going to have a sprint planning meeting a sprint review and a sprint retrospective if a team has been able to lower these overhead costs by automated testing continuous integration etc

6. These costs can be absorbed team making shorter Sprint's more desirable however if these overhead costs remain high the team may need to use longer duration sprints a team may be tempted to extend the duration of Sprint's in an effort to hide their inefficiencies remember agile projects favor shorter duration Sprint's and it is the scrum masters responsibility to coach and mentor the team so it can reduce waste irregularities and overuse and make the Sprint shorter the goal of a sprint is to deliver working software

7. Conclusion of each sprint the team should be able to deliver near releasable or potentially shippable software this is not easy especially for an existing product with a lot of legacy features but it can be done with the right technical practices and mature development processes once the sprint duration has been determined and the user stories for the sprint have been selected the duration of the sprint cannot be altered nor can any user stories be added or removed

8. The Sprint will end at the appointed time irrespective of whether the team has met the sprint goals or not this allows for effective continuous improvement if the team is unable to deliver the working software as planned the team will have to figure out why that happened and then make changes to improve going forward the product owner may choose to cancel or terminate a sprint in specific situations for example a significant change in priorities or a mid-course correction may render the current sprint backlog invalid given that we are only talking about a couple of weeks of work the cancellation of a sprint would be an extremely rare event a sprint will begin with a sprint planning meeting and end with a sprint review and retrospective


SCRUM Backlogs :-

There are three backlogs used in scrum :-

1. Product Backlog :- The product backlog is the master container of all the user stories for the project the product backlog is continually pruned or prioritized so that maximum value is delivered to the customer

2. Release Backlog :- The release backlog is a subset of the product backlog releases support the product roadmap and each release is populated with user stories necessary for that release

3. Sprint backlog :-  The sprint backlog is a subset of the release backlog and contains the user stories to be developed in the sprint as we said the product backlog contains the user stories for the entire project and it is the responsibility of the product owner


SCRUM Ceremonies :-

There are four scrum ceremonies :-

1. Sprint planning :- The sprint planning meeting is time boxed at two hours for each week of the sprint if the Sprint is going to be two weeks in duration then the time box will be four hours if the Sprint is going to be four weeks in duration then the time box for the sprint planning meeting will be eight hours it should be attended by the complete scrum team including all roles the most important aspects of this meeting are the team's capacity and the definition of done there are two approaches to selecting user stories for a sprint one is based on the velocity of the team the other is commitment driven team buy-in is critical and the goals of the sprint should be clearly understood and the desired outcome should be clearly articulated with the definition of done then there's

2. Daily scrum :- The daily scrum the time box for the daily scrum is 15 minutes regardless of the duration of the sprint length the entire scrum team including all roles should attend the daily scrum each development team member individually answers three questions what did i do yesterday what am i going through today and what are my impediments this is how the team members coordinate their work and the scrum master learns of the impediments he or she should be taking care

3. Sprint review :- The Sprint review takes place at the end of the Sprint and is time boxed at one hour for each week of the Sprint so if the Sprint were four weeks in duration the Sprint review meeting would be four hours it should be attended by the complete scrum team including all roles plus any other stakeholders who are interested in project success the purpose of the review is to demonstrate working software and obtain and assess feedback feedback may range from full acceptance of the completed software to complete rejection

4. Sprint retrospective :- The Sprint retrospective takes place after the conclusion of the Sprint review and is time boxed at 45 minutes for each week of the sprint so if the Sprint has two weeks in duration then the retrospective would be one and a half hours in length it should be attended by the complete scrum team including all roles however the product owners attendance is considered optional during the retrospective the team answers for questions what worked well what did not work well what should be done differently and what still puzzles us one or several problem detection techniques may be used in the retrospective and this ceremony is a vital part of continuous improvement at the conclusion of the retrospective the teams velocity and the projects information radiators are updated then the next sprint planning meeting takes place and this cycle continues until the project is complete


SCRUM Artifacts :-

1. Artifact for a scrum team it is the primary reporting mechanism for team members and there may be a different definition of done at various levels definition of done for a feature or user story

2. The definition of done for a sprint and the definition of done for a release it's really just a checklist of activities that add verifiable and demonstrable value to the product it's created by the scrum master in consultation with the team a sample list of the items for the definition

3. The story is fully implemented or code completed as described automated unit tests have been developed with at least 80% code coverage automated unit tests and acceptance tests in the story are passing high priority test cases have been automated and added to the regression suite note

4. This is only meant to be an example each team's definition have done will vary slightly depending on the maturity of the team and the specific situation of the team.