The Product Backlog In A Nutshell: For Scrum Beginners

The product backlog 

In scrum, the product backlog consists of all the user stories, or the set of requirements which are essentially required to manufacture the product in totality. By totality, we mean a product which possesses all the attributes as requested by the end users so that they can use it in an effective and meaningful manner to carry out their tasks or activities. In reality, the user stories are the same as product backlog items. While the product backlog item or the “PBI” is the actual terminology recommended and used by scrum, in simple language it is often referred to as a “user story” by the team members. In practice, the product to be developed is actually owned by the stakeholders or the investors who have put in money into the project. Since their role is to “own” and “decide” about what kinds of features and functionalities should be incorporated into the product, it is not practical for all the stakeholders to carry out the development process by addressing the team members on an individual basis. It is not practical to do so. Therefore, they appoint a person who acts in the capacity of a “product owner” and who represents their interests while the product is being developed and scrum methodology is being implemented in the project.
 

Product Backlog In Scrum

At the onset when a scrum project is planned, the product owner first of all clearly understands about the features and functionalities to be provided in the product. Subsequently, he or she breaks up the entire product into its constituent parts, which can be later “assembled” to “remake” the product when all the constituent parts are developed individually. The parts actually form the PBIs in the product backlog. While the product backlog is being constructed or compiled, it is necessary to determine how important the user stories are as far as the final product is concerned. While some of the functionalities associated with a particular user story may be very important, quite a few of them may not be so important from the end user or the market point of view. It becomes necessary to prioritize the user stories depending upon what kinds of functionalities and features they possess. The activity of prioritizing the user stories or the PBIs is done by the product owner.      
 

Moreover, the product backlog contains the explanation and description of the functionalities linked up with each user story. It is specifically explained in what manner the user stories are to be developed by the development team members during the sprint activity. Many times, the user story can also contain the functional and non-functional aspects needed to understand the requirement in a proper manner. The product backlog is very critical, and forms the “heart” of all scrum related activities. It should be carefully prepared by 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!

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!

Sprint Review Meetings In Scrum – Objectives, Who Participates, And Why

The main purpose of a sprint review meeting is to:

• Exhibit the development carried out by the team
• Get a proper feedback about the work completed until date
• Collaborate for a smoother functioning of the project

The reviews form a part of the inspecting and adapting process, which is one of the major advantages of scrum. Scrum methodology advocates self-learning. The scrum process supports several processes which help the team members to undertake self-correction activities, and adjudge where the project is heading. The sprint review meeting is conducted after a particular sprint is completed.
 

Sprint review meeting
Sprint reviews are informal in nature, and primarily held to display the work, in the form of user stories and development tasks, carried out by the team members during the sprint activity. The completed work is demonstrated to the stakeholders. The individuals who have invested funds into the project need to know about the status of the project and how much work has been done, so they can make proper plans to market the product. The review aims to update the stakeholders so they can get an idea regarding the quality and the quantity of development carried out in the project. It aids in increasing the user participation. The stakeholders can accept the work, or reject it in case they are not satisfied with it. They can also reject the work if the user stories fail to adhere to the acceptance criterions specified when the product items are created in the product backlog. 

The product owner represents the stakeholders’ interests. He or she remains present during the meeting and decides about the work. The stakeholders can attend the review meeting, but they are supposed to function as passive attendees, and not speak or volunteer opinions during the meeting.

Objectives of the review

• Present the user stories completed during the sprint to the product owner
• Have the user stories and tasks accepted as “Done”
• Rejected and/or incomplete tasks should be transferred back to the product backlog

 

Who attends?
The product owner, team members, scrum master, and the stakeholders (only if interested – not mandatory)

Time boxed to
1 hour per week of the sprint duration/length decided (I.e. for a 2 week sprint, the meeting should be time boxed to 2 hours, for a 4 week sprint it should be 4 hours, and so on)
 

Roles played by the scrum team members while scrum is being implemented
Several individuals attend sprint review meetings, each having his or her particular interest in the project. The roles of the individuals attending the meeting are explained as follows:
 

Product Owner
The product owner accepts the ownership of the project as far as scrum is concerned, and acts as a “true” owner on behalf of the stakeholders. He or she takes up all the responsibilities, as well as the accountability of the overall team, and represent the entire project to the stakeholders. The person:

• Presents the product increment activities
• Provides an insight into the state of the ongoing scrum project
• Generate a burn down chart displaying the work completed till date
• Successfully and effectively deliver the views and opinions of the stakeholders to the team members

Scrum Master
The main, and the only important role of the scrum master while the project is underway, is to:

• Facilitate the working
• Act as a representative of the development team

He or she ensures that scum is properly implemented at all times, in the proper manner, and should make sure that the team members are collaborating while they work. Another role of the scrum master is to resolve difficulties and remove impediments as and when they arise.   
 

Scrum Team
The entire project is developed by the scrum development team. It is important to know the main difference between the scrum team and the scrum development team – the scrum team comprises of every member associated and involved with the project, while the development team consists only of those individuals who are directly associated with the development of the user stories and the tasks which constitute the product. Their responsibilities include:

• Carrying out the development of user stories and tasks
• Sharing ideas and concepts
• Help each other out when a particular problem is faced by a team member during the sprint
• Collaborate to get the most out of scrum 

 

Company Executives/Stakeholders
The stakeholders own the project. They benefit if the project is successfully completed, and suffer a loss in the event it fails to do so. The objective of the stakeholders is to:

• Invest funds into the project
• Appoint scrum leaders to execute the project
• Monitor the development activity
• Instruct the product owner to add more requirements or user stories if needed to complete the project
• Eventually sell the product to make a profit

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 Scrum Can Help To Reduce The Risks In Development Projects – Find How Risk Mitigation Is Possible While Implementing Scrum

Scrum projects and risks
Every project in scrum, irrespective of its size and scale, is subjected to certain risks. The risks may be minor in nature, in which case they could be easily solved. Alternatively, they could be of larger magnitude, and would really tax the experience levels of the scrum master as well as the product owner to resolve them. Catering to risks is one of the main reasons why managements and “C” level executives opt for scrum methodology. 

Actually most people interpret risks in a negative way. It is interesting to know that risks can be negative as well as positive in nature, depending upon the outcome they result in. Risks, which result in a positive manner, are termed as “opportunities” while those that negatively affect the project are known as “threats”. In a simple language, a risk can be understood as a particular situation, unknown about what kind of result it will deliver when it is conceived, and which can result into an advantageous situation, or it could adversely affect the project working as well as the result the particular project is fundamentally supposed to deliver. Risk management is an inherent part of scrum methodology.
 

Minimizing risks (threats) using scrum methodology
While positive risks, or opportunities, are inadvertently welcomed, it is the risks, which create a negative effect in the ongoing project, or threats, which are of concern to scrum enforcers. Scrum helps to minimize risks in several ways:
 

Flexibility exhibited by scrum reduces business-environment-related risks
Unlike traditional development methodologies, scrum is highly flexible, and possesses the capability to add or modify the project related requirements at any time during the project life cycle. It helps the management to respond in a positive manner to threats as and when they arise. The management can easily cater to unforeseen circumstances when they arise. It is very easy to remove the user stories from the product backlog and replace them with new ones. The product owner can add new stories whenever required as per the wishes of the stakeholders. Moreover, if a particular set of requirements becomes obsolete or useless in terms of its functionality, it can be removed from the product backlog, and its development can be curtailed. This is not possible in a Waterfall method.
 

Constant and regular feedback reduce expectations-related risks
The entire project development is carried out in sprints. Each sprint is preceded by a daily scrum meeting. Scrum provides plenty of opportunities to avail feedback regarding exactly how much development has been successfully completed until date, and how much of it is still pending. The scrum board reflects the changes as and when they occur in real time, so the management is always kept informed about which user stories are currently being processed for development. Stakeholders can verify the work delivered at the end of the sprint, and if they are not satisfied, they hold the right to reject it. The investors are never caught off guard owing to miscommunication. They can always check up the development status and act accordingly.
 

Team ownership helps to reduce estimation related risks
The team creates proper and effective estimates making use of prior development related experience. Sprint retrospectives help to identify potential pitfalls likely to occur again in the future while sprint planning helps to include proper user stories for time bound and acceptable development. Team ownership helps to reduce estimation related risks.  
 

Increased transparency reduces non-detection risks 
Scrum advocates transparency. Everything and each activity carried out by the scrum team is made public as soon as possible. As a result, any risk, if it arises, is detected early by the concerned person, and the person is supposed to take up further course of action to remove the risk. Risks are detected and communicated early, and this leads to better risk handling as well as risk mitigation.
 

Iterative development reduces investment-related risks  
The delivery value is continuously presented when scrum is implemented. The basic advantage of scrum is that functionality is delivered in stages after the sprint is completed, which generally takes from 2 weeks to 1 month depending upon how long the sprint lasts. This is not possible in case of waterfall methods since the results are derived in the final stage of the product development cycle. It then becomes too late to respond to the development, and to introduce new changes because the entire project is completed by that time. Scrum helps to reduce investment related risks.
 

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

What Are Scrum Burn Down Charts? Why Are They Needed To Implement Scrum?

What is a burn down chart?
In scrum, a burn down chart functions as a graphical representation to indicate how much development activity is still left to complete the project, versus the time consumed to complete the remaining work. The work related aspect is represented along the horizontal or the “X” axis, while the days or the time factor being consumed is plotted along the vertical or the “Y” axis. A burn down chart is very useful to find out, and predict, when all the work or development activities associated with the particular project will be completed over time. In scrum, burn down charts are very important, and extensively used by scrum masters and the team members to track the status of the ongoing project. In fact, the concept of burn down charts can also be applied in a successful manner to non-Agile or non-scrum based projects.

The burn down chart is generally updated by the end of each sprint. It is updated by the scrum master. In scrum, the X-axis indicates the sprints carried out and planned, while the Y-axis indicates the number of days. The duration of the work carried out and planned, along the Y-axis, can be shown using any unit of measurement such as story points, team days, ideal days, etc as decided by the product owner, scrum master, and the team members.  

Reading the burn down chart
The burn down chart offers a convenient method to monitor the team progress on a daily basis. The horizontal axis on the bottom, the X-axis, indicates the sprint carried out as well as planned sprints, and reflects the total work required to be completed to finish the ongoing project. The vertical or the Y-axis shows the duration of the sprint, usually in days, taken by the development team to design the functionalities of the user stories available in the sprint backlog. On day zero, the first day of the sprint, the total amount of development to be carried out is maximum, since the first sprint is just beginning. As the sprint progresses, the amount of work remaining starts reducing, till it reaches the last sprint when it should ideally become zero. Alternately, a “blue” line can be drawn to represent the “ideal” working conditions with respect to the time taken and the work completed. The red line indicates the actual progress being made, and it should be compared with the blue line to find out how much the team is lacking or advancing with respect to the desired progress. Efforts should be made so that both the lines coincide with each other. This would mean that the project is progressing in the desired and expected manner.

What is the need of using a burn down chart?
Burn down charts are popular because they provide a graphical representation of how the scrum project is planned, and how it is actually progressing. A visual representation is much easier to read and understand, even for people who are not familiar with scrum methodology. The chart is frequently used to extrapolate how the work is likely to proceed over the days, and proves to be useful for estimation purposes, based upon the current level of progress. Many scrum masters consider burn down charts as motivational tools which can be used to prompt the team members to perform as per the sprint plan. Usually the chart is pinned on a whiteboard kept in the same area where the team members carry out development, and it acts as a constant reminder as to how much work is completed and how much of it is still pending. The chart not only acts as a motivational tool, but also helps the scrum master to supervise scrum in a much better manner.  

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

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! 

How Can Scrum Masters Deliver Successful Scrum Projects? Which Characteristics Make A “Good” Scrum Master?

When any organization plans to implement scrum methodology, it first decides about two individuals who play a crucial part in scrum implementation – the product owner and the scrum master. While the role of the product owner is more or less adjudged by the principles and guidelines specified in the scrum guide, it is the scrum master’s role which needs to be decided upon, as to which person can best satisfy the requirements of a scrum master. Generally, people taking up the role of a scrum master belong to a managerial class. It is generally believed that managerial personnel have the experience required to handle teams successfully and come up with positive results. However, this is not always the case, and non-managerial individuals can also take up the responsibilities if they are properly trained for it, and have the potential to deliver positive results. 

Ideally, the main question asked by the management and the stakeholders should be “Which person can best act as a scrum master and deliver results while supporting the inherent principles of scrum?” rather than ”Which scrum master can function as an ideal manager and deliver the results out of scrum implementation?” It is a fact most scrum master struggle while handling their teams when they start with their careers. Being a scrum master is not an easy task. It is important for a scrum master to follow some principles other than those laid down by scrum to win people and successfully deliver the project. Scrum is all about sharing and collaboration. It is important to know what the scrum master can do to be effective.

1. Work on a single project 
There is a Russian proverb which says if you chase two rabbits simultaneously, you will succeed in catching neither of them. If you are required to handle two projects simultaneously, and if you are putting in one hundred percent towards your work, in reality you are contributing only fifty percent to each project. It means you are not doing hundred percent justice to your projects. This is an important point which every scrum master should know and follow. Working on a single project would mean that you remain dedicated to only one project, and you can put in cent percent of your efforts in the project. One of the reasons why scrum master handle multiple projects is they fear if one of the project fails to deliver or work out, they can still successfully complete the other one, and somewhat save their reputation as successful scrum masters. Successful scrum master get invited to handle new projects, not failed ones. It is important to have confidence in one’s ability to succeed, and put in everything to make the project a distinct success.

2. Focus upon improving the team effectiveness
Scrum is about teamwork. Scrum framework promotes overall participation and contribution of all team members rather than individual contributions from team members. When scrum is implemented, it creates transparency. Members are supposed to act together as a team and deliver the results out of collaborative efforts. This is what scrum advocates. For a successful implementation of scrum, it is very important for team members to collaborate and share their findings with others. When people start focusing upon individual efforts and contributions, the “we” attitude is replaced by “I” attitude, and the person stops communicating his or her findings to others, and desires to take the credit for the development carried out. This is where scum would fail. Scrum does not require contribution from one particular “individual”, rather it desires an overall output from the entire team. Scrum masters should ensure the team members ought to collaborate and contribute in a collective manner, and should focus upon improving the team effectiveness to function as a whole unit.  

3. Facilitate rather than manage
Traditional managers and scrum master who believe in delegating their authority to a great extent may find it difficult to mold their thoughts and behavior to suit the role of an ideal scrum master. Scrum is based upon the principles of self-organization and team collaboration. One of the best ways to achieve this is to “facilitate” rather than “manage” the teams in what they do.  A few pointers my help you decide what to do and what to avoid:
 

What should be avoided:

• Avoid taking decisions on behalf of the team members
• Avoid assigning work directly to the team members
• Avoid tracking individual team member’s performance
• Avoid taking credit for the work done by the team
• Avoid engaging the team during status meetings

 What should be done:

• Aid in removing the impediments
• Set up special one-on-one mentoring sessions for each team member
• Provide suggestions and inputs regarding how to improve upon the features
• Participate in a collective manner while hiring additional or new team members
• Help each team member to plan about career development activities

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

What Should The Perfect And Ideal Daily Stand-Up Scrum Meeting Consist Of As Per The Official Scrum Guide?

The daily stand-up scrum meetings play a vital role in ascertaining that the development activity is carried out in a sustained manner. They also help to find potential pitfalls experienced during ongoing sprints. It is important to know how the daily meetings are carried out, and what they should ideally consist of. On the basis of official scrum guide specified by Jeff Sutherland and Ken Schwaber, the originators of scrum methodology, the article tries to explain in details about the daily scrum meetings.
 

Who should attend the meeting?
Everyone associated with the scrum project should attend the meeting. It is important for the scrum master and the team members to remain present, while the product owner and stakeholders too can remain present if they desire to do so.
 

What should be discussed during the meeting?
It is very important to remain focused and only discus about those topics which are directly related and associated with the sprint activity. The attendees should try not to wander off the main topic and discus about other trivia which are not pertaining to the scrum activity. In fact, the guide is specific about discussing topics which are directly connected to the sprint to be carried out during the particular day, even other topics dealing with the project, or project related issues should be avoided during the stand-up meetings. There are special provisions like the sprint retrospective meeting to discuss about such issues.

The main topics to be included during the meeting should consist of:

• What tasks were accomplished during the sprint carried out the day before?
• Which tasks are to be developed today?
• Did the particular team member face any problems or impediments during the sprint implementation? If so, what were they?

In what order should the discussions be carried out? 

There is a lot of flexibility while deciding about the order in which the discussions can be carried out during the meeting. Team members can take turns in discussing about what they have achieved, and what they plan to do on the particular day. Alternatively, the scrum master may decide who should speak first and which team member should follow the discussion. A popular method is to take up discussions regarding important tasks first, followed by the order of priority. The order of discussion can vary from project to project, and from need to need.
 

Where and when should the meetings be held?
The stand up meetings should be ideally held at the place of work, and in front of the task board. While they can be conducted almost everywhere, including conference rooms, holding the meetings in the actual place of work can help the team members to remain more focused and target oriented. The meetings should be held before the daily sprint is initiated.
 

How to sustain the energy levels during the meetings?
The stand up meetings are also commonly referred to as “huddles” by many people, simply because each team member stands very close to the next one during the meeting. The scene is much similar to the scrum used in rugby. The proximity often encourages the team members to become proactively involved in the discussion. The energy levels start rising up as each team member briefly, and professionally, discusses and outlines his or her activity for that particular day. The meeting is to be held in such a manner that the “atmosphere” becomes charged up with anticipation, and each member focuses upon the goals he or she plans to achieve during the sprint carried out that day.
 

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