SCRUM is a process in agile methodology which is a combination of the iterative model and the incremental model.
One of the main drawbacks of the conventional Waterfall approach was that the application did not proceed to the second phase until the first was finished. In the unlikely event that changes are made later in the cycle, it becomes extremely difficult to put those changes into practice because doing so would require going back and making the changes again.
Some of the key characteristics of SCRUM include:
- A dedicated and self-organized crew.
- They contain very specific and direct stories instead of lengthy required paperwork.
- Cross-functional teams collaborate as one cohesive team.
- To comprehend the functions, have close contact with the user representative.
- has a clear deadline of no more than one month.
- Scrum does a little of everything at a specific interval rather than the complete “thing” at once.
- Before making a commitment, resource availability and capability are taken into account.
To understand this methodology well, it’s important to understand the key terminologies in SCRUM.
Also read => How to Deliver High-Value Software Features in a short time period using Agile Scrum Process.
Important SCRUM Terminologies
1) Scrum Team
The scrum team is made up of seven people, plus or minus two. Together with the product owner and the scrum master, these members represent a variety of skill sets and include developers, testers, database administrators, support staff, and others.
For a specific and repetitive period, all of these personnel collaborate closely to create and implement the aforementioned characteristics. The SCRUM team’s seating arrangement is crucial to their interactions; they never sit in cabins or cubicles but rather at a large table.
2) Sprint
A sprint is a set period of time during which the work must be finished in order to be prepared for review or production deployment. Typically, the time window spans two weeks to a month.
When we state that we follow a one-month sprint cycle in our daily lives, we simply mean that we work on the tasks for a month and have them ready for review by the end of that month.
3) Product Owner
The primary user or important stakeholder in the application that needs to be developed is the product owner. The individual that represents the client side is the product owner. He or she should be available to the team at all times and has the last say.
If someone has questions that need to be answered, they should be able to get in touch with him or her. The product owner should be aware of this and refrain from adding any additional needs during the sprint or after it has already begun.
4) Scrum Master
Scrum Master is the scrum team’s facilitator. He or she ensures that the scrum team is forward-thinking and productive. The scrum master will investigate and address any obstacles on behalf of the team. The SCRUM Master acts as a liaison between the team and the PO.
He or she will update the PO on Sprint’s progress. Talk to the PO about any obstacles or issues the team may be having and work to fix them. Every day, the SCRUM Master and PO have a standup, similar to the team’s daily standup.
Recommended read => How To Be a Good Team Mentor, Coach and a True Team-Defender in an Agile Testing World?
5) Business Analyst (BA)
A business analyst is a key member of the SCRUM team. This individual is in charge of finalizing the requirements and drafting them in the necessary documents, which serve as the foundation for the creation of user stories.
He or she is the one who is contacted by the technical (SCRUM) team if there are any misunderstandings in the User Stories or Acceptance criteria. He or she then brings the matter up with the PO or, if feasible, resolves it on his own. There may be more than one BA for large-scale projects, but for smaller-scale initiatives, the SCRUM Master may also serve as the BA.
It is always good practice to have a BA when the project kick starts.
6) User Story
User stories are nothing but the requirements or features which have to be implemented.
In the scrum, we don’t have those huge requirements documents, rather the requirements are defined in a single paragraph, typically having the format as:
As a <User / type of user>
I want to <Some achievable goal/target>
To achieve <some result or reason for doing the thing>
For Example:
As an Admin I want to have a password lock in case the user enters an incorrect password 3 consecutive times to restrict unauthorized access.
There are some characteristics of user stories which should be adhered to. The user stories should be short, realistic, can be estimated, complete, negotiable and testable. The user story was never altered or changed in the middle of Sprint.
The SCRUM Master and the BA, if relevant, are in charge of ensuring that the PO has appropriately created the User Stories using the appropriate set of Acceptance Criteria. Stories that require modifications that affect the sprint release will either be removed from the sprint or completed during the allotted hours.
Each user story has an acceptance criterion that the team should be aware of and comprehend.
The user story that supplies the accompanying documentation is described in depth by the acceptance criteria. This will enable us to improve the user story even further. The acceptance criteria might be written down by any team member. The testing team uses these acceptance criteria as the foundation for their test cases and circumstances.
7) Epics
Epic is an ambiguous user story, or perhaps we might say that these are undefined user stories that are saved for subsequent sprints.
Try to relate it to real life by seeing yourself taking a vacation. You have everything planned for your trip next week, including your hotel reservations, sightseeing plans, traveler’s checks, etc. What are your plans for next year’s trip, though? You don’t have a specific strategy; all you know is that you might visit XYZ.
An Epic account is similar to your vacation itinerary for the following year; you know you might like to go, but you don’t yet know where, when, or with whom.
Similar to this, there are elements that must be included in the future but whose specifics are still unknown. primarily a feature that starts with an Epic account and is then divided into implementable tales.
8) Product Backlog
All of the user stories are stored in a sort of source or bucket called the product backlog. The Product Owner is in charge of maintaining this. The product owner prioritizes the backlog of products based on company needs, therefore it may be thought of as a wishlist.
One user story is selected from the product backlog during the planning meeting (see the next section). The team then brainstorms, analyzes, and improves the story before deciding which user stories to take, with the product owner’s help.
9) Sprint Backlog
Based on our priorities, user stories are taken from the Product Backlog as one at a time. Scrum team brainstorms on how to determine the feasibility and decides on the stories to work on a particular sprint. The collective list of all the user stories that the scrum team works on a particular sprint is known as Sprint backlog.
10) Story Points
A quantifiable measure of a user story’s complexity is called tale points. Estimates and efforts for a tale are decided upon based on the story point.
The narrative point is not absolute; rather, it is relative. Verifying that the user stories are not too large is crucial to ensuring that our estimation and efforts are accurate. The estimation will be more accurate if the user story is smaller and more specific.
Based on the Fibonacci series, each user tale is given a story point (1, 2, 3, 5, 8, 13, 21). The more complicated the story, the higher the number.
To be precise
- If you give 1 / 2 / 3 story point it means that the story is small and of low complexity.
- If you give points as 5 / 8, it is a medium complex and
- 13 and 21 are highly complex.
Here, complexity consists of both development plus testing effort.
To decide a story point, brainstorming happens within the scrum team and the team collectively decides a story point.
It may happen that the development team gives a story point of 3 to a particular story, because for them it may be 3 lines of code change, but the testing team gives 8 story point because they feel that this code change will affect larger modules so the testing effort would be larger. Whatever story point you are giving, you have to justify it.
So in this situation, brainstorming happens and the team collectively agrees to one story point.
Whenever you are deciding on a story point, keep the following factors in mind:
- The dependency of the story with other applications/modules.
- Skill-set of the resource.
- The complexity of the story.
- Historical learning.
- Acceptance criteria for the user story.
If you are not aware of a particular story, don’t size it.
Whenever a story is = or > 8 points, it is broken down into 2 or more stories.
11) Burn down chart
Burn down chart is a graph which shows the estimated v/s actual effort of the scrum tasks.
It is a tracking mechanism by which for a particular sprint the day to day tasks are tracked to check whether the stories are progressing towards the completion of the committed story points or not.
Example: To understand this, check the figure below:
I have assumed:
- 2 weeks Sprint ( 10 days)
- 2 resources working on the sprint.
“Story”-> This column shows the user stories taken for the sprint.
“Task” -> This column shows the list of the tasks associated with the user story.
“Effort” -> This column shows the effort. Now, this measure is the total effort to complete the task. It does not depict the effort put in by any specific individual.
“Day 1 – Day 10” -> This column(s) shows the hours which are left to complete the story. Please see that the hours are NOT the hours which are already done BUT the hours which are still left.
“Estimated Effort” -> Is the total amount of effort? For the “Start” it is simply the sum of the entire individual task: SUM (C5: C15)
The total amount of effort that has to be completed in 1 day is 70 / 10 = 7. So at the end of day 1, the effort should reduce to 70 – 7 = 63. In a similar way, it is calculated for all the days till day 10, when the estimated effort should be 0 (Row 16)
“Actual Effort Left” -> As the name suggests, is the effort left to complete the story. It may also happen that the actual efforts increase or decrease than the estimated one.
You can use the inbuilt function and Chart in Excel to create this burndown chart.
Burn Down Chart steps would be:
- Enter all the stories ( Column A5 – A15).
- Enter all the Tasks ( Column B5 – B15).
- Enter the Days ( Day 1 – Day 10 ).
- Enter the starting efforts (Sum of the tasks C5 – C15 ).
- Apply the formula to calculate the “Estimated Efforts” for each day (Day 1 to Day 10). Enter the formula at D15 (C16-$C$16/10) and drag it for all days.
- For each day, enter the actual effort. Enter the formula at D17 (SUM (D5:D15)) for summing up the actual efforts left and drag it over all the other days.
- Select it and create the chart as follows:
12) Velocity
Velocity is the total amount of story points that a scrum team archives during a sprint. The velocity of Scrum teams is used to evaluate or compare them. Having said that, it should be remembered that the goal is to produce a high-quality deliverable while honoring the comfort level of the scrum team, not to reach the greatest number of story points.
For example: For a particular sprint: the total number of user stories is 8 having story points as shown below.
So here will be the velocity of the sum of the story points = 30
Definition of Done:
When all stories are finished, all development, research, and quality assurance tasks are marked as “Completed,” all bugs are fixed or closed, any that can wait (such as those that are not entirely related or are not as important) are removed and added to the backlog, the code review and unit testing are finished, the estimated and actual hours spent on the tasks have been met, and—most importantly—a successful demo has been presented to the PO and the stakeholders. At that point, a sprint is considered completed.
YOU MAY BE INTERESTED IN:
DevOps Explained: Understanding the Culture, Practices, and Tools
Software Development Life Cycle (SDLC) Phases & Models