Certain Rules Which Can Help To Make The Daily Scrum Meeting Highly Effective

The daily scrum meeting, or the daily stand up, as it is commonly referred to by scrum professionals, is an integral part of the daily scrum process. The meeting is held before the sprint begins for the particular day. As per scrum methodology, the daily stand up should be ideally time boxed to 15 minutes – it should not exceed this duration whatever the circumstances may be. The three basic questions to be asked covered during the meeting are:

1. How much work has been completed in the sprint carried out the day before?
2. What work is to be taken up for development today?
3. Are any difficulties or issues faced by the team members?

The stand up should not be used to discuss any other topic, or problem, other than answering these three fundamental questions. It is important to follow this format in a strict manner to get optimum benefits.
 

In practice, many times the stand ups are not conducted in a proper manner, and the meeting fails to fulfill its objectives. The sprint may not be completed successfully, and fail to deliver shippable product at the end of its iteration. Certain reasons are responsible for this, and it is worth knowing how they can be avoided. It is possible to hold effective stand ups if the following rules are observed:
 

Everyone arrives on time
The time factor is important. The meeting should commence exactly on time, and everyone should arrive promptly so undue time is not wasted. The team members should follow proper etiquette and ensure the decorum of the meeting is maintained at all times.
 

Everyone attends the meeting
The scrum master and the development team should attend the meeting mandatorily. The entire team involved in the daily scrum should remain present in the meeting. If a team member fails to show up, or has taken a leave for the day, the scrum master should ensure that someone represents that member – at least for providing the feedback of what work was carried out the day before. Moreover, each member should remain present during the entire meeting – no member should leave it unfinished or “half way”.
 

Collaborate during the meeting
Scrum is all about sharing information and helping each other out. The team should concentrate upon contributing as a “whole” rather than concentrate upon individual contribution. The members should be ready to solve each other’s problems if they possibly can.
 

Each member addresses the entire team and not just the scrum master
A highly common mistake made by many organizations implementing scrum is to conduct the meeting in a manner such that a team member focuses only upon the scrum master, and discusses his or her work while ignoring other team members. This is wrong. A stand up is not to be used for reporting purpose. The objective is to discuss, and include everyone present in the meeting. The person addressing the meeting should include everyone.
 

Discuss the 3 important questions only
As stated above, the meeting should only be used to discuss the three basic questions – What was done yesterday, what is planned for today, and are there any problems? No other topic should be discussed in the meeting.
 

Is the Product Owner present?
The product owner should have an idea regarding how the development is proceeding during the sprint. To get first hand updates, it is important to remain present in the daily meetings. The product owner should make a point to attend the daily scrum.

Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which can help you in implementing scrum framework in your projects!

The Purpose And Goals Of Carrying Out Product Backlog Refinement In Scrum

The official scrum guide mentions about carrying out routine maintenance activities to update the product backlog, or to carry out the product backlog refinement. The exact time to be invested in the grooming activity depends upon the management, and how scrum is to be implemented in the project. A rule-of-the-thumb followed is to put in approximately 10% of the time utilized during the sprint activity, into the grooming activity. It is important to be clear regarding some of the aspects associated with product backlog refinement.

Purpose and goals of carrying out the refinement
The primary reason why the product backlog should be refined is to update or rebuild the backlog so that it remains consistent with the requirements provided by the stakeholders with regards the new features and functionalities to be included in the project. Another reason is to review existing user stories or product backlog items and decide whether they are still useful or pertinent from the development point of view, and to update the acceptance criterion and the explanation detailed in each PBI. 

It is recommended to use the “DEEP” method - detailed appropriately, estimated, emergent, and properly ordered – while prioritizing the user stories within the backlog. Larger stories or epics should be systematically broken down in to more manageable smaller ones, proper estimation by assigning relevant story points to the PBIs should be carried out,  user stories should be rearranged as per the new priorities,  and the queries regarding the development of user stories during the sprint should be effectively answered by the product owner. Whenever a meeting is planned to refine the PBIs, the objective should be to carry out enough refinement work so that it lasts for at least three future sprints.

Product Backlog Grooming In Scrum

Duration and frequency of the grooming activity 

Each activity and meeting is time boxed in scrum. Following the same principle, the product backlog refining or grooming activity should be time boxed too. However, in practice, there is no pre-designated activity or a meeting for planning and carrying out the product backlog refinement activity in the same manner as the sprint planning meeting and the sprint retrospective meeting is held. Backlog grooming is carried out more as a routine activity than anything else in scrum, and the guide does not exactly specify how much time or efforts should be invested in the activity. Perhaps a possible reason could be that the product development and creation of product backlogs vary from project to project, and it is difficult to standardize how the grooming activity should be carried out since the size and nature of the product backlog cannot be adjudged.

In practice, ideally time equivalent to 10% of the total time spent during the sprint activity should be allotted for the product refinement. For a two week sprint consisting of a total of 6 working hours per day and 14 sprint days per sprint, the time to be allotted should be approximately 10% of 6 hours x 14 days  = 8.4 hours (10% of 6 hours x 14 days = 84 hours). This could be rounded up to one working day. Since the refinement activity is to be carried out on a consistent basis, investing additional time could lead to decreased productivity and an extended product release date – something that should be avoided.  In actual practice, this rule suffices to a great extent.

 
Who should participate in the grooming activity?
Besides the product owner, the grooming sessions should be attended by the development team members and the scrum master. The stakeholders can participate in the sessions too, but their participation should be a passive one, and they should not volunteer opinions, or try to disturb the sessions in any way or manner. Moreover, the product owner should try to limit their numbers during the sessions so it does not become overcrowded and difficult to hold the meeting.

Maintaining a proper approach
It is important to remain focused, and the product owner should be clear whether a particular product backlog item should be estimated again, or it ought to be detailed in greater depth, and additional explanation provided regarding its acceptance criteria. The team members should remain focused upon understanding the PBIs and if required they should demand explanations regarding the acceptance criteria and how the development should be carried out during the sprint activity.

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Reasons For Carrying Out The Product Backlog Grooming Activity

What is product backlog grooming?
The main objective of the backlog grooming session is to improve the product backlog and rearrange the user stories or the product backlog items in accordance to the new priorities determined by the stakeholders or the team members. Grooming sessions can also be held to verify the product backlog items whether they have the information necessary to develop the user stories in a more efficient manner. The scrum guide does not try to define what a backlog grooming session actually is because the “grooming” activity may vary from project to project. It is difficult to standardize the process so that it can suit all types of projects. The grooming session are generally held to:

• Write or rewrite the product backlog items or user stories if they are not properly stated or described
• Reschedule or re-prioritize the product backlog items based upon the recent updates provided by the stakeholders
• Segregate epics or large user stories into smaller and more manageable ones
• Re-estimate the story points linked with the user stories
• Update or add new acceptance criteria to the user stories
• Analyze the product backlog for planning purposes

 

Product Backlog Grooming In Scrum

Different reasons why the product backlog is refined
The product backlog can be rescheduled or refined for a number of reasons depending upon the changes occurring in the market conditions or new features demanded by the end users. At times, it becomes necessary to weed out less important tasks and replace them with effective ones. The product owner may decide to reprioritize the backlog if he or she feels some of the user stories need to be developed on a priority basis. Usually, the product backlog grooming activity or product refinement is carried out because of three main reasons:
 

Refinement carried out by the stakeholders
As the market conditions keep on changing over time and new competitive products are launched, it becomes necessary for the stakeholders to do away with some of the functionalities in the product which have become obsolete and are no longer needed. It is meaningless to spend time and efforts over features which are not likely to score for the product in the market, and which no longer have a selling value. The investors and stakeholders remain in touch with the ongoing market trends, what the end users require, and how the selling value of the product can be increased by introducing new set of features and functionalities while the product is being developed. The stakeholders may decide to “overhaul” the project by removing some of the features and functionalities, and replace them with new ones, which have added market and selling values.
 

Informal product backlog grooming 

One of the important objectives of carrying out the product grooming activity is that the team members too attend the grooming sessions, and it offers an opportunity for the product owner to explain the user stories to the development team. The product owner takes the opportunity to describe and explain the new set of product backlog items to the team members and answer questions regarding the business values of the user stories. It is a great way of understanding what the product eventually focuses to do when it is launched in the market and how it is supposed to behave when fully developed. Generally, the grooming sessions are succeeded by the sprint planning meetings, and the team is able to prepare in advance for the planning meetings in a more meaningful manner. Since the team members become more familiar with the exact functionality associated with the user stories, it becomes easy for them to segregate the user stories into development tasks during the second half of the sprint planning meeting.
 

Periodic refinement carried out by the team members
It is important to carry out “routine maintenance work” and keep the product backlog “in shape” so it becomes easy to plan the sprints. As the sprints progress and development is carried out during the sprinting sessions, some of the tasks are completed and new functionality is developed. At time, the functionality developed can be shared with other resources to be developed, and it is important to identify such resources so duplicate or repetitive development activity can be avoided and time can be saved. While implementing scrum methodology, the grooming session help to weed out the repetitive tasks and get the backlog back into “shape”. It also provides an opportunity to the team members to ask for clarifications and demand explanations for the stories they find it difficult to understand to the product owner. 
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

How To Hold An Effective Backlog Grooming Session

What is backlog grooming?
Also referred to as “Story time” sessions, the main purpose of the backlog grooming session is to make improvements in the product backlog and rearrange the items as per new priorities presented by the stakeholders and the investors. Grooming sessions are also held to recheck the product backlog items or the “PBI”s as to whether they contain the necessary information which can aid in developing the user stories in a perfect manner by the development team. The official scrum guide does not venture to define exactly what a backlog grooming session is since the “grooming” can vary from project to project and management to management. The process cannot be standardized to suit all types of projects and all requirements. However, in a nutshell, the grooming session can be used to:

• Write the user stories from scratch if they are not properly defined or described in the product backlog
• Re-prioritize the user stories contained in the product backlog on the basis of recent updates availed from the stakeholders
• Break down large user stories or “epics” into smaller parts
• Estimate or update the story points associated with the PBIs
• Add new or updated acceptance criteria
• Analyze the backlog for technical planning

Product Backlog Grooming In Scrum

Why are backlog grooming sessions necessary?
One of the common problems experienced  by team members while scrum is being implemented, and one which often troubles the stakeholders and the management to a large extent is that the sprint planning meetings seem to last forever, and even after investing proper time and efforts, issues and problems still tend to arise and persist during the sprint activity. It can lead to frustrations for the team members since scrum methodology supports time bound functioning of various constituent processes, and a particular activity cannot extend beyond the time allotted for it to function. Scrum advises time boxing of all related processes, especially the sprint activity. One of the commonest causes why problems occur during scrum implementation is because the product backlog is not properly “groomed” to perfection, and the user stories are not correctly defined or prioritized. It is very important to hold grooming sessions to verify and re-validate the product backlog items from time to time so that a true value of ownership is reflected in the user stories, and the project is completed in a cost effective manner. 
 

How to hold effective product backlog grooming sessions? 
A couple of guideline can help you conduct a meaningful and effective product backlog grooming session:
 

Have a clear goal
During the grooming session, the product owner should maintain an attitude which says “This is exactly what I want to accomplish today” and proceed with that attitude during the session. It is very important to be clear as to exactly for what reason the session is to be held, and what needs to be accomplished from it. The goal of holding the grooming session should be clear, not only to the product owner, but also to the team members participating in the session.
 

Explain the user stories and plan for the next sprint
Carry out the grooming session in a manner such that everyone feels involved and becomes clear about the goals associated with the user stories in the product backlog. The product owner should ensure that each team member has a clear understanding regarding the goals linked with the stories, and if any team member needs clarifications, the product owner should provide them as soon as possible. The product owner should also explain the objectives and specify the goals to be achieved in the next sprint to be carried out after the sprint planning meeting. This helps the team members to prepare for the sprint planning meeting to be held after the grooming session.
 

Limit the participation of stakeholders “chicken” in the session
Stakeholders and investors, often colloquially known as “chicken” in scrum have the right to attend the sessions. The product owner should instruct the stakeholders to participate as passive listeners and not volunteer any opinions, or try to influence the session in any way or manner. The person should further limit their numbers to a bare minimum so that enough space is available to conduct the session in a healthy and easy manner without any hindrances from the guests.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

The Role Of A Product Owner

The product owner in scrum
The product owner is a very important person in scrum. He or she owns the product on behalf of the company and the stakeholders. The person is responsible for the overall success of the project, and should oversee that the product development is carried out in a proper and planned manner as per the implementation rules suggested in scrum methodology. To carry out the responsibilities in an effective manner and make proper decisions at the correct time and in the correct manner, the product owner is endowed with certain powers, and authority, and the person should utilize those powers to ensure that the project is executed in a successful and desired manner. 
 

In real life, the role of the product owner varies in accordance to the nature and requirements associated with the project. Several factors such as the ongoing market conditions, the product development life cycle and stage, and the management influence how the product owner should set up priorities in a project. The participation of the product owner is very important in the initial stages of the scrum project when the product backlog is to be created and sprint durations are to be set up. The product owner’s work profile is not an easy one, especially if the organization is new to scrum, or if the individual lacks enough experience working as a product owner. 
 

What decides the role of a product owner in real life?
The best way of knowing about what a product owner should ideally do to be considered as a “perfect” product owner is to refer to the official scrum guide and pick up hints as to what the guide suggests. It is important to know that scrum is all about adaptation and being “agile” in its implementation. When scrum is to be implemented in a project, it should be done so in a manner such that the objectives are best fulfilled in the manner desired by the stakeholders. Many a times, the product owner has to change his or her working style and adapt to:

• What the project demands in terms of responsibilities
• The goals set up by the stakeholders
• What the scrum team is capable of delivering
• What the person is capable of delivering in terms of productivity and goal achievement on a personal level

When scrum is being implemented, the product owner is expected to engage himself or herself in a proactive manner and facilitate the working as and when possible. The person is generally expected to:

• Collaborate closely with the team members on a consistent basis
• Guide and direct the scrum team
• Monitor and actively manage the product backlog
• Answer questions and provide solutions to problems and questions when they arise
• Provide appropriate and useful feedback to the stakeholders and the scrum team whenever required or demanded
• Signing off work

In simple words, the product owner takes the back seat, decides what should and should not be done, and make sure the product is shipped at the correct time.

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

What To Consider Before Writing User Stories In Scrum So They Can Be More Effective And Meaningful

User stories in scrum
A user story is the main functional unit in scrum methodology. When any project is taken up for development using scrum, the specific requirements for that particular project is stated by creating a set or development requirements, which are termed as user stories in scrum. Usually the product owner creates the product backlog – the list of requirements needed to develop the project. The product backlog items are referred to as user stories by scrum professionals. Once the product requirement list is created, a small set of the requirements (user stories) are transferred to the sprint backlog during the sprint planning meeting for development purposes. The stories are explained to the team members in the first half of the sprint planning meeting. During the second half, team members distribute the stories after breaking them down into development tasks. A sprint backlog is prepared in this way. Subsequently, the team starts developing the functionality of the user stories during the daily sprint. In scrum, the entire project is governed on the basis of the user stories.
 

The official scrum guide does not attempt to provide a specific definition that can describe the “structure” of a particular user story. The guide actually explains what a user story is, and what part it is supposed to play in the project. It fails to provide a standard format which can explain as to how a user story should really look like. Maybe, the reason why the guide fails to provide a structural definition is because development requirements can vary from one particular project to another.  So, it becomes difficult to standardize a specific format compatible to all types of projects.  The guide, however, states that the user story should ideally be composed of three constituent parts, or include there main aspects:

1. A written description or a graphical representation of the entity which forms a part of the project
2. A detailed conversation, or an explanation which additionally describes the functionality in greater details
3. The acceptance criteria or “Done” meaning which specifies what the entity should include, how it should function, and the particular manner how it should migrate or integrate into the project

What should be considered while writing or creating user stories
While writing the user stories, certain points are important, and should be adhered to for the user stories to be effective and developmental:
 

Stakeholders should create or write the user stories
The investors and the stakeholders are funding the project for financial gains. Each project has a financial value attached to it in terms of how much the project will be worth in the market. The stakeholders know which user stories are important, and which functionality will increase the value of the project. Therefore, they are the ideal individuals to define and create the list of requirements or the user stories. The product owner carries out the work on their behalf, and represents their interests while the project is being implemented.
 

Using simple tools to represent user stories
In the manual system, stories are written down on index or story cards specially designed for scrum. The scrum index cards are very convenient to work with, and are generally pinned on the scrum board while the sprint is underway. It is important to use a tool that is small in size, so it can be easily stored and pinned on the scrum board. It should be easily readable, simple to understand, and effective. The more simple and effective the tool is, the easier it would be for the team to understand and use it.
 

Time to be allotted to the user story
Scrum advocates time bound activities. Each activity in scrum has a certain duration associated with it, and is “time boxed”. It is important not to exceed the time limit to get the most out of scrum. Each user story is allotted a certain duration within which its development should be completed. It is essential that each user story is completed in the time allotted to it since it has a certain importance value (story points) attached to it. The project turns out to be cost effective only when the right duration of time is allotted to each user story, and each story is completed in the time allotted to it. If the time limit is not allotted, the project becomes expensive and its ROI decreases.
 

Describing important non-functional aspects
Certain user stories need to be explained in further details so the team members can properly understand them. The user stories may be very important in terms of how they provide a solution for a particular end-user related requirement. They may or may not be technically complex, but it may be important for the team members to know what part the user stories are likely to play, and how much important they are as far as the overall project development is concerned. Such non-technical aspects of user stories should be explained properly so a better overview and understanding of the project related requirements is availed.  
 

Fixing the story priority
Each user story has a certain level of importance attached to it development. It is important to prioritize the user stories, so the correct time can be fixed for its development. Important user stories, or those which have more importance attached to their development, should be assigned a higher priority, and sufficient time should be allotted for completing them. On the other hand, less important stories ought to be assigned less time and priority because they do not carry much financial value with regards the functionality they offer. 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

What Are User Stories In Scrum? Why Is It Necessary To Associate Story Points To Them?

User stories and scrum projects
User stories constitute the “heart’ of any scrum based project. The development associated with a particular scrum project is defined and processed in the form of user stories. The product owner defines the project by creating and prioritizing the requirements in the product backlog in the form of user stories. During development, a small segment, or a set of user stories is taken from the product backlog, and transferred to the sprint backlog. During the second half of the sprint planning meeting, team members take up user stories from the sprint backlog, and distribute them amongst themselves, based upon their levels of expertise. Each member subsequently segregates each user story into individual development tasks for programming purposes. Thus, the actual process flow of the project is dependent upon user stories.

What, exactly, is a user story?
A user story, in scrum, fundamentally helps to explain and describe a particular functionality which is of a certain value to a stakeholder or an investor, and which forms an inherent part of the actual project. In simple words, the entire project is broken down into smaller segments or parts, which are prioritized by the product owner on the basis of importance they carry in the project. The segments or parts are the user stories. The priority is determined on the basis of what kind of functionality the particular user story is supposed to deliver, and how much “value” or financial importance it carries in the project. Stories, which deliver important functionality, are prioritized as “high value” stories, while those, which are associated with less importance, are “low value” stories, or simply “stories”.
 

As far as the official scrum guide is concerned, there are no specific definitions which explain the “structure” of a user story. The guide proceeds to explain what a particular user story is, and what part it plays in the scrum project. It, however, fails to standardize a formal “format” or a “design” as to how a particular user story should “look like” or appear. Perhaps the main reason why the scrum guide prefers to ignore defining the exact structure is because requirements can change from project to project and from one development platform to another.  It is not possible to standardize a format which can be compatible to all the types of projects.  The guide, however, explains the user story as composed of three constituent parts, or rather it should include there aspects:

1. A written and/or a graphical description or explanation of an entity that forms an inherent part of the project
2. A conversation, description, or explanation which further explains the functionality in greater, or tries of define the “flesh” of the entity
3. The acceptance criteria or benchmark which defines what the entity should really include, how it should exactly function, and the manner in which it should integrate in the project

Assigning importance or value to user stories – “story points”
Once the concept of a user story becomes clear, perhaps the next logical question ought to be how user stories can be prioritized, or in what manner importance can be correlated to a particular story. In scrum, story points are arbitrary units of measurement, used to signify or imply the worth of a particular story or a product backlog requirement, in terms of a numerical value. The numerical value can include a fractional part, but it cannot be a negative number, or an exponential value. The product owner decides how important a particular user story is from the ROI point of view, i.e. how much worth it is to the investors and the stakeholders in terms of its market value, and assigns a number to it based upon its level of importance. 

There are certain factors to be considered while assigning the story points (Please refer to our Scrum knowledge base for additional reading and references). The story points are very important, and essential while creating estimates pertaining to sprint activity.

       
Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

How Can A Scrum Master Successfully Carry Out The Servant Leader Role While Implementing Scrum Framework?

What does the term servant leader actually mean?

Many scrum reference books and articles explicitly state and describe the role of the scrum master as a servant leader. While most of the definitions try to state the same meaning, they can often lead to confusion as to which definition is perfect and should be followed. The importance of a definition comes into the picture once its meaning is properly understood. So, rather than concentrating upon the definition, it would make more sense to understand what the concept really means. In a nutshell, the role of being a servant leader would actually refer to maintaining a positive and humane attitude towards the team members, being sensitive towards their difficulties and problems, and putting in efforts to act as a facilitator so that goals can be achieved in a collaborative manner, with each team member contributing towards the fulfillment of the project in a proactive way. It is important for a scrum master to possess certain characteristics to be a successful “servant leader”.

1. Listening

An individual who is a good listener can also make informed decisions and successfully solve problems. It is important for the scrum master to listen attentively, with an open mind. The person should try to pick up pointers during the daily scrum meetings as to what the team members are really trying to say, and what kinds of problems they are really facing. Some individuals are extroverts and find it easy to speak about their problems in a crowd, and demand solutions from others.  Introvert individuals may find this very difficult to do, and so it would be up to the scrum master to encourage such individuals to open up and be vocal about their problems. Moreover, the person should also try to encourage self-organization and self-learning amongst team members. If the team is facing impediments, it becomes necessary to engage with the issue in a proactive manner and start finding solutions, rather than wait for the team to approach the scrum master with the particular issue. To be a good servant leader, the scrum master should also be a good listener.

2. Awareness

While leading teams, it becomes imperative to develop a holistic view and look at things from a general point of view, rather than be concerned about the micro level issues when a particular issue or problem arises. It is important to look at problems from a higher level and get an overall picture of where the issue is actually heading to before arriving at a consensus with the team members. It is also required to look beyond the role and scope as a programmer or a developer and grasp the problem at its root level before striving to provide solutions. Scrum methodology advocates that the scrum master should not get directly involved with the development work and start directing the team members. At the same time, the servant leader role indicates that the scrum master should act more as a facilitator and help the team members to resolve their problems by providing guidance and advice, even on an individual basis if required. Therefore, it becomes necessary to strike a correct balance between the two aspects of the role.

3. Persuasion

Traditional project managers can be autocratic while delegating their authority. Scrum is in antithesis of autocracy – it supports teamwork and collaboration. The team works as a whole and delivers results. Moreover, the scrum guide indicates a specific role for the scrum master. He or she should primarily supervise, and ensure that scrum is properly implemented, and followed by the team members. Rather than issuing commands and orders, the servant leader role encourages persuasion – discuss and talk with the team members, and encourage them to do things rather than demand action and activities from them. 

Subscribe to the permanent free version of the Quickscrum project management tool to get an idea about how the tool works and what it has to offer.

All About Sprints And Sprint Meetings – In A Nutshell

Overview

The sprint is the main point of activity for any scrum project. During a sprint, the development team delivers a certain portion, or a “slice” of the actual development activity to be carried out as defined in the product backlog. During a sprint, the development activity can include a host of other things in addition to the actual development work. This can include the documentation, user manual creation, testing and debugging functionality, or even checking cross platform compatibility. Each activity during the sprint can be understood as a task. When user stories are transferred to a sprint backlog by the product owner, the development team further segregates each user story into its individual tasks i.e. each story is broken down into smaller tasks to make it more manageable and developable. Each user story is assigned a story point which determines its potential value. The story points help to generate an estimate as to how many user stories can be included in the sprint backlog based upon the team’s ability to carry out the development.

The entire development is carried out in the form of sprints. Usually, a sprint lasts for two weeks, however, technically they can extend up to three to four weeks depending upon how scum is being implemented by the product owner and the scrum master. Sprints are also known as “iterations” in more simple terms. Sprints are supervised by scrum masters. As per the scrum guide, a scrum master should be a passive participant during the sprint. His or her job is to ensure that the team members properly follow scrum rules when the sprint is underway. At the end of the sprint, user stories are developed into shippable products, each with its own functionality and importance. 

 

Sprint planning meeting

A sprint planning meeting is held before the sprint commences. It is attended by the product owner, the team members, and the scrum master. During the sprint planning meeting, the product owner transfers some of the user stories from the product backlog into the sprint backlog for development purposes. The meeting is actually held in two parts:

1. First half of the meeting

During the first half of the meeting, the product owner explains about the user stories which have been included in the sprint backlog. He or she explains about the acceptance levels and the importance of the user stories to the stakeholders. Team members are free to ask questions to the product owner if they require explanations regarding some of the user stories.

2. The second half of the meeting

During second half of the sprint planning meeting, the team members breakdown the user stories in the sprint backlog into smaller, and more manageable tasks, which are taken up for development purposes. Generally, the team members decide unanimously how to distribute the tasks and user stories amongst themselves. Team members take up work as per their skill sets and development expertise.

Sprint retrospectives

A sprint retrospective meeting is held after the sprint is over. The main purpose of the meeting is to evaluate the sprint which has just completed, and what lessons should be learnt from it. A lot of discussion occurs during the meeting, and both the product owner and the scrum master try to envision what could possible go wrong in the future sprints. They contribute their expertise as well as their experience, and try to identify impediments, and seek solutions for potential problems which may occur in the near future.  

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!