Meetings or rather term ceremonies, play an essential role in the Agile framework. The Agile framework in today’s world is called the Scrum Framework. Meetings give Agile or Scrum framework regularity and structure. In this framework, all meetings or ceremonies are required to continue the recurring process. This helps identify and solve hurdles in the process. Each meeting has its specific purpose and deadline, it helps improve the productivity level of the team.
Difference between Waterfall and Agile
Agile framework
Let us have a quick look at how the roles are divided into different elements of the Agile framework.
There are 4 main elements in an agile framework; they are Product Owner, Scrum Master, Developer / Architect and Tester. The below image helps us to understand the responsibilities of all 4 roles.
What is Scrum?
Scrum is an Agile framework, which helps teams to work together to achieve goals or complete projects. The framework helps teams to organise, learn and experiment with their approach to solve problems.
Scrum is not limited just to a software development team, any team can use it. Scrum basically means a set of roles, tools and meetings which helps the team to manage and structure their work on a day to day basis. The below image demonstrates the process.
Let us look at each element in the process.
- Project backlog
- User Stories
A user story is the smallest element of an Agile framework. It is a short and simple explanation of a feature/requirement by a user or customer. This is written by product owners, team, define the Scrum master role.
- User Stories
- Format to write User stories.
- As a (role) I want (action) so that (business value)
- As a (role) I want (action) so that (is optional)
- In order to (get benefit) as a (role), I want to (take an action)
User Story Types.
- Theme – Program level objective to drive strategic initiatives
- Epic – high-level user story, depicting end-to-end customer journeys
- User Story – Requirement at a granular level, ready for development
- Definition of Ready
- Defines the criteria to start the development of a user story.
- Business value is aligned with product goals.
- The user story is estimated and prioritized.
- Dependencies are identified and backlogs are created and linked.
- The team will have all the required support from the management.
- Performance goals are clearly defined.
- All testing requirements are well documented and understood.
- User stories are reviewed and discussed with business stakeholders.
- Definition of Done
- Defines the criteria of completion of a user story.
- Unit and integration tests have passed.
- Features are developed and tested to meet requirements.
- Code and user documentation is complete.
- Code checked into the repository after all quality scans.
- The user story is reviewed and accepted by the Product Owner.
- User story testing and automation are complete at all levels.
- Deployment related tasks are completed.
- Product Backlog is updated and the burn-down chart reflects the latest status.
- Backlog Refinement
In this product backlog items (PBIs) are created by the product owner or stakeholders. Initial prioritization takes place and the definition of ready is established. This takes place during the sprint process and will last up to 1 hr, can be done once or twice a week depending on the sprint requirements.
The goals of Backlog Refinement are:
- Explaining in detail the features and PBIs for the next 2 sprints.
- PBIs are sized and acceptance criteria is updated.
- PBIs meet the Definition of Ready.
- Sprint Planning Meeting
At this stage, the team meets and discusses the upcoming sprint. To start you need to have few requirements, like prioritize product backlog and team size. The planning should be done on the first day of the sprint. The meeting can go up to 4 hrs depending on the size of the sprint and can be done once per sprint.
The goal of this Sprint Planning Meeting is:
- The product owner sets goals to achieve and pass them on to the scrum master.
- The Team and PBIs are resized and acceptance criteria is updated.
- The Team then creates work tasks and assigns them.
- Updating the tool with the sprint scope.
- The Definition of done is established at this stage.
- One of the most critical commitments is it should be clearly understood by all.
- The tasks should be achievable without affecting the quality and sustainable pace of the project.
- The meeting should be attended by team members, product owners, and scrum masters. Stakeholders are optional.
- The meeting should be led by the scrum master.
- Daily standup meetings
These are short meetings which take place every day by the team. The time duration is between 15 mins to 30 mins. Each team member should answer 3 questions.
What did I do yesterday? What will I do today? Any obstacle which is affecting the progress?
- Sprint Review
The team should be ready with the list of features or PBIs to be demonstrated. This marks the end of the sprint. The duration can last up to 1 hr or more depending on the sprint size. The sprint review is done just once at the end of the sprint. In this meeting, the goal is to demonstrate the working software, collect feedback and discuss the upcoming sprint. This meeting is attended by the team members, scrum master, product owner, and stakeholders. The meeting is arranged by the product owner and the team.
- Sprint Retrospective
This meeting is just like the sprint review meeting, happens at the end of the sprint but is attended by team and scrum master only. This meeting can last up to 1 hr and takes place once the sprint has ended. The purpose of this meeting is to the prime directive and have a team discussion on what went well?, What could be improved? Callouts and recognitions. The team discusses the upcoming action items for the next sprint. The meeting is attended only by the team and scrum master.
