Different Meeting in Agile (Scrum)

There are set of meetings which are conducted if you are practicing Scrum.  Each meeting have specific agenda, purpose and frequency and Scrum Master should ensure that each meeting sticks to its plan and achieves its intended purpose.

Here are the meetings which comes with practicing Scrum. 

Sprint Planning Meeting
Frequency: Once at the beginning of every Sprint cycle.
Duration: 4 to 8 hours depending on Sprint length.  As a rule of thumb, it is 2 hours per week of sprint.  So if you are having 2 weeks sprint then 4 hours for planning and so on.
Purpose: Determine what work to be done in the sprint, preparing backlog and communicate to everyone what will be completed in the sprint. Development Team commits to the plan and Sprint backlog. Also, In first half of the meeting entire team involving dev team, scrum master, product owner meets and they prioritize the Product Backlog.  In first half product manager identifies the user stories that team feels it can commit to completing in the sprint based on prior experience.  In Second half of the meeting development team and scrum master breaks the story down into tasks and they determines how they plan to develop and test agreed user stories. At the end of this meeting team creates the plan for the sprint and agrees on Sprint backlog.

Daily Stand-up Scrum Meetings
Frequency: Daily
Duration: 15 min
Purpose: Main purpose of this meeting is to collaborate with other team members and communicate Risks. In these meetings, each team member answers 3 questions:
- What I did since last call
- What am I going to do till next call
- Is there anything which is blocking me (impediments) from achieving my sprint goals. If there are any impediments than Scrum Master records that. Team doesn't try to resolve issues in this meeting and Scrum Master work outside this meeting to bring impediments to resolution.

Sprint-end Review Meetings
Frequency: Once at the end of the end of the sprint
Duration: 2 to 4 hours
Purpose: Show the work (demo) to the stakeholders and customers that team accomplished in the sprint and receive feedback.  Also, review the work that is planned but not completed.

Sprint-end Retrospective Meetings
Frequency: Once in the sprint. Usually on the last day of the sprint after Sprint Review Meetings
Duration: max 3 hours
Purpose: This meeting is facilitated by Scrum Master. Two main questions are answered in this meeting i.e., What went well during the sprint? and What could be improved in the next sprint?

Overall purpose of this meeting is to implement continuous improvement in processes.  Based on the brainstorming and analysis team decides to implement new processes, update existing processes and/or continue to follow good processes.

 Optionally some teams do have few other meetings like

Backlog Refining Meetings
Frequency: None
Duration: None
Purpose: This is not Standard Scrum practice but many team follows it to manage the quality of product backlog items better. This is an ongoing process where team and product owner reviews the product backlog and re-prioritized (if required).  If required large Product backlog items are broken into smaller items and more details about the items are added.  This helps team during the Sprint planning meeting to pick and complete the user stories in effective manner.

Scrum of Scrums Meetings
Frequency: Daily
Duration: None
Purpose: This is a technique which is very useful when there is large team working towards same goal.  This large team is divided into multiple scrum teams to focus on one particular area.  These individual scrum teams designates one member in their team to represent their work to other teams.  All teams discuss their work in Scrum of Scrums daily meeting with the agenda of focusing on areas of overlap and integration.This designated team member could be technical contributor in the team or Scrum master of the team.  As Jeff Sutherland commented, Scrum of Scrums is not meta scrum but its responsible for delivering the working software of all the teams to the Definition of Done at the end of the sprint.

The Agenda of Scrum of Scrums Daily meeting are to get answer to four questions:
- What has your team done since last call
- What will your team going to do till next call
- Is there any impediments for your team
- Is there any impediments your team going to put to other teams

Development or Scrum team role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss Third and the last of these 3 roles in detail which is Development or Scrum Team. 

The Development team or Scrum team (now onwards called scrum team) is responsible for delivering potentially shippable increments (PSI) of the product (Sprint Goals) at the end of each Sprint.  The Scrum Team builds the product that the customer is going to consume like the software, website, etc.  High performing scrum teams are highly collaborative and self-organizing with a very high degree of autonomy and accountability.  The Scrum teams are "cross-functional" and it includes all the expertise necessary to deliver the PSI.

Effectively the Scrum teams are made up of 7 individuals plus or minus 2 with the cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.) but can scale up using scrum of scrums.  Also, see Agile Methodology Myths busted. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.

The Scrum team have total authority over how the work gets done, which tools & techniques to use, and which team members will work on which tasks. The people who do the work are the highest authorities on how best to do it.  Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.

The Scrum team should possess all of the skills required to create a potentially shippable product. Most often, this means we will have a team of specialists, each with their own skills to contribute to the team's success.

The Scrum Team has the following responsibilities:

• Is cross-functional, with seven (plus/minus two) individuals
• Selects the Sprint goal and specifies work results
• Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal
• Organizes itself and its work
• Demos work results to the Product Owner.
• responsible for completing user stories to incrementally increase the value of the product
• self-organizes to get all of the necessary work done
• creates and owns the estimates
• owns the “ how to do the work” decisions
• avoids siloed “not my job” thinking

 

Scrum Master role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss second of these 3 roles in detail which is Scrum Master.

The Scrum Master is the facilitator for the development team which uses Scrum.   The Scrum Master is responsible for making sure a Scrum team lives by the values and practices of Scrum. The Scrum Master is accountable for removing impediments (obstacles) so that team is able to deliver the committed product goals and deliverables. The Scrum Master makes sure that team do not over-commit or under-commit on the stories during a sprint.

The Scrum Master is not a traditional Team Lead or Project Manager role.  The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of the rules of the Scrum, Chairs meetings, and challenges the team to improve.  The Scrum master role excludes any people management responsibilities.  There is no role of project manager in Scrum at all and their responsibilities are divided up among the three Scrum roles.

The Scrum Master facilitates the daily standup meeting also called scrum meeting and becomes responsible for removing impediments that are brought up by the team during scrum meeting. The Scrum Master is not the project leader and cannot be not held accountable for outcomes.  The team as a whole is responsible for outcomes.

The Scrum Master has the following responsibilities:

• Helps team to reach consensus for what can be achieved during the sprint
• Represents management to the project
• Is responsible for enforcing the rules of the scrum
• Runs the Daily stand-up Scrum meetings
• Removes impediments
• Shields the team from external interferences and distractions
• Ensures that the team is fully functional and productive
• Enables close cooperation across all roles and functions
• Helps team to stay focused

Product Owner role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss first of these 3 roles in detail which is Product Owner.

Scrum Product Owner is a Project's key stakeholder.  The Product Owner represents the stakeholders and is the voice of the customers.  The Product Owner have a vision of what he/she wishes to build and convey that vision to the scrum team.  This is most important for the successful starting of any Agile software development project.  He/She is accountable for ensuring that the team delivers value to the business. The Product Owner does this by writing or having team write customer-centric features called user stories.  The Product Owner then ranks and prioritizes these user stories and creates/adds them to the list of product features which is called product backlog. 

Scrum teams should have only one Product Owner and this role should never be combined with that of Scrum Master. Product Owner is often combined with the role of Project Manager as they have the best visibility regarding the scope of work.  The Product Owner is the person having solid understanding of the users, the market place, competition, etc


The Product Owner has the following responsibilities:

• Holds the vision for the product;
• Represents the customers
• Owns product backlog
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every 30 days, as needed
• Accept or reject work results
• remains available to answer developers questions

The product owner is responsible for the first of the three Scrum ceremonies : Sprint Planning
The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog.

In return for the Scrum team's commitment to completing the selected tasks, the Product Owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

The best product owners show commitment by doing whatever is necessary to build the best product possible – and that means being actively engaged with their teams. Business savvy is important trait for the agile product owner because he or she is the decision maker regarding what features the product will have. That means, the agile Product Owner should understand the market, the customer and the business in order to make sound decisions.

Finally, communication is a large part of the product owner responsibilities. The product owner role requires working closely with key stakeholders throughout the organization and beyond, so he or she must be able to communicate different messages to different people about the project at any given time.

Agile Methodology Myths busted

Myth-1: Each team member in Agile Scrum method should do everything

Agile says Scrum teams should be self-organizing and cross-functional.  It means scrum team as a whole should be having necessary skills to create product increment.  This doesn't mean that each individual in team should be cross-functional.  In Agile, each team member is called developer having different skills like Designer, Programmer, Tester, etc.  Agile doesn't mean and doesn't want to kill the expertise of the people.  


Myth-2: Agile means no documentation

Agile never says that there should be any documentation.  Documentation is important but focus should be on working software instead of comprehensive documentation.  Agile says, we should get rid of documentation which doesn't add value.  For example: Low level design docs are important for future reference as well but creating estimation of how many defects testers are going to open in release doesn't make any sense. How can anyone forecast, how many defects would be raised :-)


Myth-3: Agile means no planning


On the contrary, Agile requires more planning.  Only difference between planning in Waterfall and Agile methods is when planning is done.  In Waterfall model, whole planning is done at the start of the release cycle, whereas in Agile small amount of planning is done to fix the Time and Cost of the project at the start of the release and team continue to do sprint planning to pick up the tasks which is most important for the customer


Myth-4: Agile means lack of discipline


This is utmost false. Agile brings sense of responsibility and discipline in each team member.  It brings people together and commitment at each step and it demands that each individual be responsible to deliver whatever he has agreed too. The daily interactions enhance this sense of responsibility, which is not the case when people hide behind documents and bureaucratic obstacles.  So, it actually demands more responsibility and a discipline enforced by the collective.

The rule of keeping a sustainable pace – which means avoiding overtime – requires a serious commitment against procrastination. The ideal velocity of the team should be determined, and maintained. The iterations are short, so any lagging will be promptly noticed.

What is "Agile" Methodology

Lets first try to define what is Agile Methodology?

Agile Methodology is an alternative development methodology to traditional project management like waterfall model. Agile Methodology encourages rapid and flexible response to changes.  Heart of Agile Methodology is defined in Agile Manifesto.


Components which comes into consideration when we do project management.

1. Time
2. Budget
3. Scope
4. Quality

In Traditional Waterfall model, Time-Cost-Scope remains fixed and if project is behind schedule it makes quality go down.  Whereas in Agile Model, Time-Quality-Cost remains fixed and scope varies as per time-boxed iterations.



Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan 

The meanings of the manifesto items on the left within the agile software development context are described below:

• Individuals and interactions: In agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software: Working software will be more useful and welcome than just presenting documents to clients in meetings.
• Customer collaboration: Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• Responding to change: Agile development is focused on quick responses to change and continuous development.

Agile Manifesto is based on 12 principles:

• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than months)
• Working software is the principal measure of progress
• Sustainable development, able to maintain a constant pace
• Close, daily co-operation between business people and developers
• Face-to-face conversation is the best form of communication (co-location)
• Projects are built around motivated individuals, who should be trusted
• Continuous attention to technical excellence and good design
• Simplicity- The art of maximizing the amount of work not done - is essential
• Self-organizing teams
• Regular adaptation to changing circumstances

Well-known Agile software development methods:

• Agile Modeling
• Agile Unified Process (AUP)
• Crystal Clear
• Crystal Methods
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• GSD
• Kanban (development)
• Lean software development
• Scrum
• Velocity tracking

Everything you want to know about Agile Scrum Team

Scrum team builds the product (software, website, etc) that the consumer consumes.  Scrum ideally consists of core roles and additional roles.  But, whenever we talk about scrum team that means we are talking about core roles only. 

Core Roles

• Product Owner
• Development team
• Scrum Master

Additional Roles

• Stakeholders
• Managers
• Users

 Scrum teams consists of following features:

• Team size for scrum team should be 7 plus or minus 2
• Team should be cross-functional.  Cross-functional teams have all the competencies required to accomplish the work without depending on others who are not part of the team. As we can see there are no testers, coders, programmers, in scrum team.  All the members except Product Owner and Scrum master are called developers.  Developers could be having different skills like programmer, tester, designer, documentation, etc. 
• Team should be able to do everything required to achieve sprint goals.  There is an misconception that every team member should be able to do everything.  Every scrum team should have developers with variety of skills like programmer, test, etc but every scrum team member is not supposed to do everything
• Team should be Self-organizing.  Self-organizing teams chooses how best to accomplish their work, rather than being directed by others outside the team.
• Scrum team should decide on scrum goals and results
• Scrum team demos work to the Product owner and other stakeholders