There are many phases of Software Development Life Cycle. Starting with Requirement Phase, Design Phase, Coding (Development) Phase, Testing Phase, UAT (User Acceptance Testing)
In this SDLC cycle where does the testing phase start? Actually it start at the beginning when the requirement gathering starts. QA’s are meant to do the complete analysis of the requirement including impact analysis. Agile Methodology completely takes care of all these phases in a very disciplined way.
What is Agile?
Agile in simple terms is to accept the change and implement the same.
What is Agile Methodology?
Agile Methodology is the method that is used worldwide as a process. Agile processes generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software.
There are different agile methods like SCRUM, Extreme Programming etc. The most popular method is Scrum. In this article we will understand how the SDLC works with SCRUM method.
Note: Please read What makes agile development the need of this progressive technology?
What is Scrum in Agile?
Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.
- A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
- “Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.
A Scrum process is distinguished from other agile processes by specific concepts and practices, divided into the three categories of Roles, Artifacts, and Time Boxes.
The actors in Scrum are:
- Product Owner (PO)
- Scrum master
Who is Product Owner? The Scrum Product Owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team.
Product Owner is one who creates the product backlog. Product backlog has all the feature details in the form of stories that is to be taken as a part of a sprint. Product Owner breaks down the feature in the form of stories. Prioritize the stories as per the requirement, and those are taken in the sprint accordingly.
What is a Scrum Master? The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholder, who is referred to as the product owner.
The ScrumMaster does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint. The ScrumMaster role is commonly filled by a former project manager or a technical team leader but can be anyone.
What/Who is Scrum Team? Scrum teams are cross-functional, including the skills (but ideally not the job titles) of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. It is recommended all team members be located in a team room, and collaborate more intensely than a traditional team.
Story comprises of below points:
1) Story Title – This describes the story in short
2) Story Status – Open, In Progress, Testing, Approved, Reopened, Closed
- Open– new story status
- In Progress– It’s under development
- Testing– It’s in testing phase, bug fixing/retesting are also done in this phase
- Approved– QA approved
- Reopened– PO reopens
- Closed– Approved by PO
3) Story Description – This is section has the complete description about the story
4) Story Points – Team is asked to rate the complexity of the story in the form of story points. Story points are given to the story in the estimation meeting.
5) Story Priority – PO decides the story priority when to be done in the sprint
6) Acceptance Criteria – As per the acceptance criteria team develops the requirement. PO before signing off checks whether all the acceptance criteria are met as per the plan.
7) Testing Criteria – QA’s before signing off checks whether all the testing criteria are met as per the requirement
8) Environment – This section includes the OS, window, browser details, mobile devices etc.
What is Sprint?
All the activities are carried out in the form of sprints. Sprint period can be defined as 1 month, 2 weeks or 1 week. Depending on the sprint period, the features or functionality are taken up in the sprint.
Estimation and Sprint Grooming Activities
Estimation Meeting: PO, Scrum master and Team all three are the part of the estimation meeting. All sits together and estimate the story points. Team does this activity by using poker cards. Poker cards has different cards with number on it that represent the Fibonacci series i.e. 1, 1, 2, 3, 5, 8, etc.
Sprint Grooming: PO and Scrum master play major role in this activity. In this meeting scrum master understands what are the features that are to be developed for the release. Risk analysis and story prioritization is also part of this activity. This is done one week prior to the sprint start.
PO, Scrum master and Team all three are the part of the sprint planning.This happens on the zeroth day of the sprint or the first day. All the members involved in this understands the story and acceptance criteria. The story is breakdown into tasks, and is allocated to the team members.
During the sprint, If there is any change in requirement, then it is taken as a priority and accordingly the other story is de-prioritized. The story is breakdown into small tasks like test case writing, test case review, Updating test case, test case execution, bug retesting etc.
Each tasks has its hour allocation. Once completed, hours are logged against that task with proper comments.
DURING THE SPRINT :
- First day of the sprint, the team starts their work. Developer starts story development, QA’s starts writing test cases
- Once the development is done, QA’s perform functional testing
- Bugs are raised accordingly
- Developer resolves the bugs, those are retested by QA’s
- Once all the story acceptance criteria are met, QA’s mark it as approved state
- PO re-verifies it, and accordingly either closes or reopens the story
- All these activities are traced by scrum master and team during their daily standup
- Daily standup meeting – Scrum master and team are the part of it. Daily morning, all meet and discuss on what task they worked yesterday, on what they are working today and if team has any blockers. Scrum master is responsible for resolving the blockers and solving the team queries.
- If team is not able to finish off 1 or 2 stories due to some reason, these are carry forward to the next sprint.
- Sprint fails if team is not able to deliver all the stories in the sprint demo
PO, scrum master, team and other stakeholders are the part of sprint demo. Team is asked to showcase the features they have developed in the sprint during sprint demo. If any change requirement comes, it is incorporated and developed as a part of next sprint. This is done on the last day of the sprint. So the first and last day are not considered as a part of the story development.
Scrum master and team plays major role in sprint retro. In this meeting, all sits together and discuss what went wrong in the sprint, what new things we can try in order to achieve the best and on time delivery. Recommendation are part of this, if any team member has done good job, he/she is appreciated.
Stakeholder Engagement – Agile provides multiple opportunities for stakeholder and team engagement – before, during, and after each Sprint.
Transparency – All the actors are aware about the current status and sprint delivery details.
Allows for Change – change is accepted and implemented.