One of the most dominant Agile approaches is Scrum. It’s very popular and widely used. Agile is a development methodology based on iterative and incremental approach. Scrum is one of the implementations of agile methodology.
The below terminology is used within the Sprint:
- Scrum Master: A Scrum project Is managed by a Scrum Master, who can be considered as much a consultant or coach as a manager.
- Sprint. Scrum has a fundamental 30-day development cycle called a Sprint, preceded by pre-Sprint activities and post-Sprint activities.
- Daily Scrum: A short (less than 30 minutes) daily Scrum Meeting allows the team to monitor status and communicate problems.
The Product Backlog is used for Planning within the Sprint. Project planning is based on a Product Backlog, which contains functions and technology enhancements. Two meetings are held – one to decide the features for the next Sprint and the other to plan out the work.
The Flow for the tasks in a Sprint are:
Product Backlog > Sprint Backlog > Sprint > Working increment of the Software.
Scrum uses lightweight queue-based management and work-breakdown mechanisms.
- Product Backlog queue: a low-tech customer-managed queue of demand requests for products.
- Sprint: At launch time, a Sprint (30-day time-boxed iteration) does just-in-time planning.
- Sprint Backlog: queue for Sprint work.
A Daily Scrum is very notable and very visible. It’s a daily standup that all members of the team attend. It is run and handled by a Scrum Master, who holds daily scrum and acts more as a facilitator and runs interference for the core team when blocks or issues arise.
The Core Roles within a Sprint are:
- The Product Owner represents stakeholders and is the voice of the customer. The Product Owner is accountable for ensuring that the team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.
- The Development Team is responsible for delivering potentially shippable product increments at end of each Sprint. The Team is typically about 3–9 people with cross-functional skills. Team does actual work (analyze, design, develop, test, technical communication, document, etc.).
- Scrum is facilitated by a Scrum Master – who is Accountable for removing impediments for team to deliver sprint goal / deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures process is used as intended, is the enforcer of rules, and protects the Team and keep it focused on the tasks at hand.
A Sprint is a basic unit of development in Scrum. The Sprint duration is typically around 1 – 4 weeks. Each sprint is Preceded by a planning meeting, where the tasks for sprint are identified and an estimated commitment for the sprint goal made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.
During Sprint, team creates finished portions of a product (an increment). Features going into a Sprint come from the product backlog, which is a prioritized list of requirements. Which backlog items go into sprint (sprint goals) are determined during Sprint Planning Meeting.
A Sprint Goal sets up minimum success criterion for the Sprint and keeps the team focused on the broader picture rather than narrowly on the task at hand. The team then determines how many selected items can be completed during the next sprint. These then go into the Sprint Backlog. The Sprint Backlog is property of the development team, During a sprint, no one is allowed to edit the sprint backlog except for development team. Development is time-boxed, A Sprint must end on time. If the Requirements not completed for any reason, they are omitted and returned to Product Backlog.
Scrum enables self-organizing teams and Encourages co-location of all team members.
A Product backlog is an ordered list of “requirements” that is maintained for a product. It Contains Product Backlog Items ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.
Features added to the backlog are commonly written in story format (what, when, who, where, how). They have to be as detailed as possible. The product backlog is the “What” that will be built, sorted in the relative order it should be built in. It’s open and editable by anyone. The Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team.
The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. (1, 2, 3, 5, 8, 13, typically up to 21)
Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items.
The Product Owner is responsible for the product backlog and the business value of each item listed. The Development Team is responsible for the estimated effort to complete each backlog item. The Team contributes by estimating Items and User-Stories, either in “Story-points” or in “estimated hours.”
The Sprint Backlog is list of work the Development Team must address during the next sprint. The List is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. Thinking is what is done by the Development Team asking “Can we also do this?” and adding stories/features to the sprint backlog. The Development Team should note velocity of previous Sprints (total story points completed from each of the last sprints stories) when selecting stories/features for the new sprint. Use number as guide for “effort” they can complete.
Stories/features are broken down into tasks by Development Team and Should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. The Tasks on sprint backlog are never assigned; tasks are signed up for. by team members during daily scrum, according to priority and member skills. This Promotes self-organization of Team, and developer buy-in. The Sprint backlog is property of Team, and all included estimates are provided by the Development Team.
Some of the Terminology used in Sprints:
- Sprint burn down chart: Daily progress for a Sprint over the sprint’s length.
- (User) Story: A feature added to the backlog is commonly referred to as a story; has a specific suggested structure. Done so development team can identify user, action and required result in a request; simple way of writing requests anyone can understand.
- Example: As a Peebee user, I want a tools menu on the edit screen so that I can easily apply font formatting.
- A story: is an independent, negotiable, valuable, estimatable, small, testable requirement. Stories may be clustered into epics (a group of related stories) when represented on a product roadmap or further down in the backlog.
- Tasks: Added to story at beginning of a sprint and broken down into hours. Each task should not exceed 12 hours, but it’s common for teams to insist that a task take no more than a day to finish.
Definition of Done (DoD): The exit-criteria used to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful.
- Velocity: The total effort a team is capable of in a sprint. The number is derived by adding all the story points from the last sprint’s stories/features. This is a guideline for the team and assists them in understanding how many stories they can do in a sprint.
- Impediment: Anything that prevents a team member from performing work as efficiently as possible.