Did you know that one of the main drawbacks of the traditional Water Fall model is – as soon as the first phase of the project is completed, the application does not move to another stage. And if there are some changes at a later stage, then making those changes becomes very difficult, because it will involve having to review previous stages and having to redo the requirements. Scrum fixed that.
Some key features of SCRUM
The team organized themselves and gathered to work together. There are no large documents required, instead there is a very accurate set of documents. Cross functional groups work together as a single unit. Communicate closely with user representatives to understand the features. There is a defined timeline for up to a month.
Instead of doing the whole thing all at once, Scrum does a little bit of everything in a set amount of time. Team resources and availability are carefully considered before committing to the customer anything.
To understand this method, it is important to understand the key terms in SCRUM.
1) Scrum Team
The Scrum Team is a group of 7 people + or – two members. These members are a competency group consisting of developers, testers, database managers, supporters, etc. along with the product owner and scrum owner. All of these members work together in close collaboration for a recursive and defined period, to develop and implement the said features.
The seating arrangement of the SCRUM team plays a very important role in their interaction, they never sit individually, but will be a large table.
2) Sprint
A sprint is a predefined time frame or time frame during which work must be completed and the team must make it available for review or ready for production deployment. This amount of time usually ranges from 2 weeks to 1 month. When the team says the team is on a 1-month Sprint cycle, it only means that the team will work for a month for the assigned tasks and will have to make the application available for demo by the end of the month.
3) Product Owner
The product owner is the primary stakeholder or the main user of the application to be developed. The product owner is the customer representative. He / she has final authority and is always ready to answer any questions for the project team. He / she should be ready when anyone on the project team has something to clarify. It is important that the product owner understands and does not specify any new requirements in the middle of the sprint stage or when the sprint has begun.
4) Scrum Master
The Scrum Master is a facilitator of the Scrum team. He / she ensures that the scrum team is productive and progressive. In case of any obstacles, the scrum master tracks and solves them for the team. The SCRUM Master is the intermediary between the PO and the group. He / she keeps the PO informed of sprint progress. If there are any barriers or concerns for the team, discuss them with the PO and address them. Like the daily standup of the group, a SCRUM Master standup with PO will have to be with the team every day.
5) Business Analyst (BA)
A business analyst plays a very important role in SCRUM. This person is responsible for receiving the completed request and re-editing it into the required documents (based on desired user requests). If there is any ambiguity in the customer request / User Acceptance criteria, he / she is the person that is approached by the technical team (SCRUM) and then he will post it on the PO or if If not, you can solve it yourself. In large scale projects, there may be more than 1 BA but in small scale projects, SCRUM Master may also play a role as BA. It is always a good practice to have a THREE word during the project launch phase.
6) User Story
The user's story has nothing but requirements or features that must be fulfilled. In scrum, we don't have those big request documents, instead, the requirements are defined in a concise, concise text, often formatted as: <User / user type> I want <Some goals / goals achievable> to achieve <some results or reason for doing this> Example: As an Administrator, I want to lock the password in case the user enters it Incorrect password for 3 consecutive times to restrict unauthorized access.
There are some things to keep in mind in requests from users that need to be respected. User requirements should be brief, realistic, can be estimated, exhaustive, negotiable and testable. User requests are never changed or changed in the middle of a Sprint. It is the responsibility of the SCRUM Master and the BA (if possible) to ensure that the PO has accurately outlined the user's Story with an appropriate set of Acceptance Criteria. If any changes will affect the demo release at the end of each sprint, sprint treatment will be made, such requests will be removed from the end of the sprint or they will be followed. Plans available.
Each user's request has an acceptance criteria that needs to be defined and understood by the project team.
Acceptance criteria are also supported by the user. It helps further refine the user story to be more specific. Anyone in the group can write down the acceptance criteria. The testing team will set their test cases / conditions based on these acceptance criteria.
7) Epics
Epics are unclear user stories, or we can say that these are unidentified user stories and kept for future sprints.
An Epic is like you will need to plan your next summer vacation where you only know you might want to go, but where, when, with whom, all of these details Do not know at the present time.
In a similar way, a feature starting with an Epic and then being divided into stories can be made.
8) Backlog
The product backlog is a place that holds all the user's requests. Document held by the Product Owner. Product backlog is imagined as a wish list of product owners but low priority, it is given based on business needs.
9) Sprint Backlog
Based on priority, user requests are taken from the Product Backlog each time. The Scrum team will need to determine the feasibility and decide if those requirements are chosen to work in a specific sprint. A list of all of these user requests that the Scrum team operates on a combined sprint is called the Sprint backlog.
10) Story Points
A quantitative indication of the complexity of a set of user requests. Based on each point, estimates and effort for a request will be determined. To ensure that our estimates and efforts are accurate, it is important to check that user requests are not too large. The more accurate and smaller a user's request is, the more accurate the estimate.
11) Burn down chart
The recorded chart is a chart that shows the actual ability compared to the project team's original estimation ability
This is a specific sprint tracking mechanism, daily tasks are tracked to check if the requirements are approaching the completion of the committed story points.
12) Velocity
The total number of story points a scrum group saves during a sprint is called Velocity. The Scrum team is evaluated or referenced by its velocity. Keep in mind that the goal of the reference here is NOT to achieve the maximum story score, but to have a quality that can be delivered to the customer, respecting the comfort of working for the Scrum team.
A Sprint is marked Done when all stories are completed, all dev, research, QA tasks are marked 'Done', all bugs are closed, code reviews and Unit Test are completed. Therefore, the estimated hours have met the actual number of hours given in the missions and most importantly, the successful demo has been delivered to the PO and stakeholders.