Scrum: method to implement agile in SDLC

Agile itself is not a specific way of working; it is generic set of principles or priorities which are outlined in the Agile Manifesto. While below said are the specific flavours or frameworks of agile.

Agile Methods:

Agile methods are different ways to implement agility in software development life cycle. Some methods focus on practices and some methods focus on management. Some common methods, those are being followed in industry, are as follows:

• Adaptive Software Development(ASD)
• Agile Modelling
• Agile Unified Process(AUP)
• Crystal Clear Methods (Crystal Clear)
• Disciplined Agile Delivery
• Dynamic Systems Development Method(DSDM)
• Extreme Programming(XP)
• Feature Driven Development(FDD)
• Lean software development
• Kanban (development)
• Scrum
• Scrum-ban

 Among all above agile methods, Scrum is the most widely used method. It is an agile project management framework. We can conclude scrum as a management framework for incremental product development using one or more cross-functional, self-organizing teams. There are some defined roles, meetings and artifact used in Scrum. Teams can follow their processes within this framework.

 Sprint: Scrum describes iterations (in agile short time frames that typically last from one to four weeks) as sprints. Sprint involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing.

Sprint starts with a planning meeting to decide the spring goal. At the end of sprint a shippable product is demonstrated to stakeholders followed by a retrospective meeting where the process is reviewed and lessons for the future are identified.

 Scrum Roles: There are 3 roles in scrum described as below:

1. Product Owner: Product owner represents the stakeholders and customers. PO is only person to ensure that team delivers value to business. The PO writes customer visions of the product (typically in form of User stories), prioritize them and keep it in the Product Backlog. PO is the final arbiter of requirement questions to the development team.

2. Development Team: It is a cross functional team including members with programming skills, testing, UI designers, DBA etc. This team is self-organizing/self managing. The dev team is responsible for delivering potentially shippable increments of product at the end of each Sprint.

3. Scrum Master: Scrum master is he who facilitates the scrum processed. This role is not traditionally any team lead or project manager. The SM helps team to resolve impediments, creates environment to team self-organization and no management authority on the team. The Scrum Master is the enforcer of the rules of Scrum, often chairs key meetings, and challenges the team to improve.

Scrum Meetings: There are 4 types of meetings done in Scrum. Before going into details of each meeting agenda held while doing Scrum, here it is important to understand couple of artifacts of Scrum Product Backlog and Sprint Backlog.

A Product Backlog is a list of requirements for the product. High priority requirements are kept on top and least important items are kept subsequently down in the list. Product backlog can have whatever needs to be done in order to successfully deliver the product. Anyone can add items in the product backlog. But it is the responsibility of product owner to prioritize the business value of backlog item and reorder the product backlog. The product backlog and the business value of each backlog item is the responsibility of the Product Owner. The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours. But sizing is done during sprint meetings.

A Sprint Backlog is the list of items, the Development Team takes for the next sprint. The list is derived by selecting product backlog items from the top of the product backlog until the Development Team feels it has enough work for the sprint. The Development Team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guide line of how much “effort” they can complete. Sprint Backlog is owned by development team.

Now we know about Product backlog and sprint backlog. We are good to go to understand the different scrum meetings:

1. Sprint Planning Meeting: The purpose of this meeting to plan that what needs to be done in next sprint. This meeting is done once and at the beginning of every sprint. Product owner and development team are the attendees for this meeting and scrum master acts facilitator. In this meeting sprint backlog is prepared for the upcoming sprint. Items to work are pulled from top of product backlog. Team is responsible for selecting amount of work as per its capability and sprint duration.

If the top of the Product Backlog has not been refined, a major portion of the planning meeting should be spent doing this, as described in the Backlog Refinement Meeting section.

The timebox for sprint planning meeting for a 30-day sprint is maximum 8 hours. It will be managed proportionally for shorter sprint.

The outcome of this meeting is sprint backlog which has refined and committed items from Product Backlog.

2. Daily Scrum Meeting: Each day during the sprint execution daily scrum meeting occurs at the same time. It is also known as Daily Stand up. In this meeting every team member reports others team member on below 3 points:
3. What have he done since yesterday?
4. What does he plan for today?
5. Any impediments or blockers

The length of this meeting should not exceed from 15 minute. There is no real boss in this who takes the status but team member report their status within each other. Product Owner may or may not join this meeting. But it is always useful if product owner joins DSM.

During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals.

3. Sprint Review Meeting: This meeting is done after sprint execution. In this meeting team demonstrates a working product increment out from the sprint to product owner and other interested people.

After the demonstration, product owner reviews sprint backlog and declares which item he considers as done. Incomplete items are returned to the product backlog. If any newly discovered scope is found that is added to product backlog.

The Sprint Review Meeting is the appropriate meeting for external stakeholders and end users to attend. It gives the opportunity to visualize and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements. New products, particularly software products, are hard to visualize in a vacuum. Many customers need to be able to react to a piece of functioning software to discover what they will actually want. Iterative development, a value-driven approach, allows the creation of products that couldn’t have been specified up front in a plan-driven approach.

4. Sprint Retrospective Meeting: At the end of every sprint, team sits for sprint retrospective meeting. At this meeting thoughts are flows on question what went well during the sprint? What can be improved?

Dedicated ScrumMasters will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety which not found in most organizations. Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility.

A common impediment to full transparency on the team is the presence of people who conduct performance appraisals.

5. Backlog Refinement meeting:

The Backlog Refinement Meeting lacks an official name and has also been called “Backlog Grooming,” “Backlog Maintenance,” or “Story Time.”

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. Teams have found it useful to take a little time out of Sprint Execution — every Sprint — to help prepare the Product Backlog for the next Sprint Planning Meeting.

In the Backlog Refinement Meeting, the team estimates the amount of effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them. Large vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team in estimation.

It is very common practice now-a-days that Product backlog items are written in the form of User Story. An oversized PBI (Product backlog item) is called as epic. This can be further drill down to granular form as user stories. The user stories reaching to a common goal can be grouped in the epic.

Read Similar Posts