How Are Sprint Review Meetings Different From Sprint Retrospective Meetings In Scrum? Where Do They Differ?

The primary objective of a sprint review meeting is to present the development work carried out by the development team, avail proper and reliable feedback regarding the work completed until then, and support collaboration. The review meetings are a part of the inspecting and adapting process associated with scrum. Scrum methodology supports self-correction and self-learning methods. There are several processes, which help the team to self-correct, and find where the project is heading. Both the sprint review and the sprint retrospective meetings are conducted after a particular sprint is completed. It is important not to get confused between the two. 

Sprint review meeting
Sprint reviews are informal meetings, and specially conducted to present the work – user stories and development tasks – carried out and completed by the team members during the sprint. The work completed is ideally demonstrated in the form of a “demo” to the stakeholders and investors. The main idea is to put the completed work in front of individuals who have invested into the project, so they can get an idea regarding the quality and the quantity of development carried out. It helps to increase the user participation levels. The stakeholders can subsequently accept the work, reject it if they are not satisfied, or if the work does not adhere to the acceptance levels as specified at the time of creating the product backlog items. The product owner represents the stakeholders’ interests, and he or she decides about the work during the meeting. In reality, the stakeholders may attend the meeting, but they are passive attendees and are not allowed to speak or volunteer opinions during the review. The product owner does all the talking. 

Goals

• Present the sprint development work to the product owner
• Get the user stories and tasks accepted as “Done”
• Rejected and incomplete tasks to be transferred back to the product backlog

Who attends?

• Product owner, team members, scrum master, stakeholders (only if interested)

Time boxed to

• 1 hour per week of the sprint duration/length (I.e. for a 2-week sprint, the time to be allotted = 2 hours for the meeting and for a 4-week sprint = 4 hours, and so on…)

 

Sprint retrospective meeting
The entire team, product owner, and the scrum master ought to put in efforts to find out about what lessons need to be learnt from prior sprints, what more can be done to streamline the sprint process, and what kind of pitfalls and problems are likely to arise in the future and how they can affect the project.    

Goals

• What can and should be learnt from the sprints already completed
• Identify potential pitfalls and impediments likely to affect the team during the sprint activity
• Plan for the next print

Who attends?

• Product owner, team members, and the scrum master

Time boxed to

• 3 hours

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!

Rules For The Daily Scrum Meeting – What Every Member Should Do To Make The Sprint Successful

The daily scrum meeting rules
The daily standup or the daily scrum meeting is very important while implementing scrum. The purpose of the daily standup is to initiate the sprint activity for the particular day, with a little bit of discussion pertaining to what was done in the sprint the day before i.e. yesterday, and what the team plans to do on the particular day i.e. today. It is imperative for the team members to follow rules which can help to implement scrum in a successful manner. Moreover, the team members are also required to maintain a certain decorum while participating in the daily standup.
 

The important rules required to conduct a beneficial standup and implement scrum in a healthy manner can be briefly summarized:
 

1. Held in the same place

Ideally, the daily scrum should be held in the same place, and at the same time every day. The best time to hold the meeting is in the morning, before the development team initiates the actual daily sprint. The potential of the team can be best tapped when members are fresh, and open to ideas. 

2. Should be time boxed

The meeting should be time boxed and not extend beyond the stipulated 15 minutes allotted for it.

3. Encourage active participation

The scrum master should encourage active participation and ensure the members are collaborating during the meeting, as well as during the sprint.

4. Attend the daily standup

All team members, including the product owner and the scrum master should ideally attend the daily standup. In case of a distributed team, the remotely working team members should participate using online media and tools .

5. Maintain timings and must be prompt

The members attending the meeting should maintain timings and must be prompt. They should be mentally prepared with their brief presentations and what questions they need to ask, if required, during the meeting.

6. Each member gets a chance to talk and discuss

The scrum master should ensure each member gets a chance to talk and discuss without any inhibitions. Irrespective of the process you follow about which member should speak first, each individual should disclose what work was done in the prior sprint, and what he or she plans to do on that day.

7. Three important questions

The three important questions:

• What activity was done the day before?
• What activity is planned for today?
• Are there any issues or problems which impede the sprint process?

Should be discussed in the meeting by each development team member participating in the daily sprint.

8. Should refrain from asking questions other than those mentioned

The team members should refrain from asking questions other than those mentioned in point 7. The discussion should not include topics pertaining to designing, trouble shooting, fixing bugs, project analysis, etc.
 

9. Not indulge in gossip

Team members should not indulge in gossip or carry out any other discussion not pertaining to the daily scrum.
 

10. Only one individual speaks at a time

When the meeting is being conducted, only one individual speaks at a time. All other members should listen carefully, and make notes if required.
 

11. Address the team as a whole

The member should address the team as a whole, and not just focus or concentrate upon the scrum master while providing the feedback.
 

12. Query or problem is solved as soon as possible

During the meeting, if any team member requires help or guidance regarding a particular point or problem faced by the individual, the scrum master should ensure that the query or problem is solved as soon as possible.
 

13. Stakeholders should remain quiet and not intervene

Non-team members and the stakeholders can attend the meeting if they desire to do so, but they should remain quiet and not intervene during the meeting. They should not indulge in any activity which can distract the team members from carrying out the meeting in a proper manner.
 

14. Provide ample of room

Non-team members should provide ample of room to the development team so they have enough space to conduct the meeting, and make notes.
 

15. Scrum master holds the right

The scrum master holds the right to prevent any non-team member from attending the meeting if he or she deems fit to do so.
 

16. Any member not supporting the rules should be asked to leave

Any member, team or otherwise, not supporting the rules and regulations can be asked to leave the meeting and the vicinity by the scrum master.
 

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

Conducting The Daily Scrum Meeting Or The “Daily Stand Up”

The daily scrum or standup meeting
One of the primary responsibilities of the scrum master is to hold the daily scrum meeting, or the “daily stand up”, as it is commonly referred to by scrum professionals. The person is required to get the product owner and the team members together for the meeting. The objective is to avail information pertaining to three important aspects of the daily scrum:

• Which tasks have been completed in the sprint carried out the day before, or yesterday?
• What tasks are to be taken up for development for the particular day, or today?
• Did any team member face any hurdles or impediments during the sprint? If so, what were they?

Duration of the daily standup
The daily scrum meeting is time boxed to last for a maximum of 15 minutes, and should not extend this period.

Purpose of the daily scrum
The main purpose of the standup is not to resolve issues or provide solutions to problems. The aim is to apprise the team members regarding the current status of the project, and ensure they collaborate and contribute jointly as a team during the development activity. If any team member faces a problem, and it is mentioned during the daily standup, it is the scrum master’s responsibility to ensure that the issue is resolved at the earliest. The solutions to such problems are provided by the scrum master and the product owner.
 

Holding stand-ups for non-collocated or distributed teams
One of the major concerns, and also a probable problem at times, for the scrum master is to hold the daily standup when teams are not located in the same office or geographical area. Many companies now use and implement scrum methodology, and in certain cases, the entire development team may not be located in the same place. With off-shoring activities becoming popular by the day, soon it would be common scenario to hold meetings with team members residing in different states and even different countries. Scrum advocates that the daily scrum should include all the team members. In fact, the term “scrum” is akin to the scrum huddle often practiced in rugby, or “rugger”. With large distances separating the team members, it may not be possible to hold a daily scrum in which all team members can be physically present.
 

A possible way out is to use electronic media and facilities to decrease the geographical distances.   Team members can use Skype and videoconferencing tools to participate online in the meeting. The scrum master has to instruct every remotely located team member to log on at a particular time when the daily scrum is to be held, and explain that the members should make sure the hardware and software tools are properly functional at the time of the meeting.
 

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!

Importance Of Time Boxing In Scrum – Why Time Plays A Very Important Part While Implementing Scrum

Scrum methodology and the time factor
It is very important to control the time factor while implementing scrum projects. Scrum methodology advocates time bound activities, and one of the main reasons why scrum is capable of adapting itself to the changing development related conditions is because each activity is closely linked with a certain time frame. Whether it be the sprint planning meeting, or a sprint retrospective, none of the activities are supposed to extend beyond the time limit set up for the particular activity. It is the only way scrum can work and function properly.  If an activity cannot be completed in time, it is either recalled, or reconsidered for another “go” or iteration, but under no circumstances the time limit can, and should, be extended. Setting up time limits for activities is also termed as “time boxing” in scrum. 
 

Importance of time boxing in scrum
Time boxing ensures that the development team members do not consume too much or extra time than that allotted to complete a user story or a development task, and at the same time the team members should not run out of development requirements before the sprint time is over. Scrum is all about balancing things and aspects, in the proper manner. The basic reason why time plays such an important part in all scrum related activities is team members should not spend or invest undue time and efforts after tasks, other than that suggested or recommended. Each requirement or the product backlog item has a certain value or importance attached to it. An item that has a significant market value attached to it is more important, and the team can afford to spend more time for its development. On the other hand, items which are less important or have a lesser value attached to them should be developed by investing least resources and time. Basically, it is a question of attaching the proper degree of importance to the items in direct relation to their worth.
 

Which activities should be time boxed while implementing scrum methodology?
Every activity in scrum should be ideally time boxed. It is the duty of the scrum master to ensure that activities remain time boxed, and the scrum team does not over extend it. The main features, which are an inherent part of scrum methodology, should be mandatory time boxed.
 

Sprint planning meeting
The sprint planning is conducted in two parts, with each part not extending more than four hours each. Therefore, the entire sprint planning meeting should not extend more than eight hours excluding the lunchtime in the afternoon.
 

Daily scrum meetings or the stand ups
Daily stand ups are brief, and should not extend more than 15 minutes each day.
 

Daily sprint
Ideally, the daily sprints should last for 8 hours. However, they may be set up to last for more time depending upon the complexity of the user stories and the time allotted to the project. The total sprint time should be decided unanimously by the team members and approved by the scrum master as well as the product owner. Whatever time is decided, it should be fixed and kept consistent on a daily basis.
 

Sprint review meetings
The review should not extend more than 4 hours for a month long sprint.
 

Sprint retrospective meetings
The retrospectives should also not extend for more than 4 hours.
 

Advantages of being time boxed
The main advantages of maintaining tight time schedules are:

• The development process becomes more efficient
• The overheads are drastically reduced
• The velocity of the team increases significantly

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

Means Of Communications For Collocated And Distributed Teams While Implementing Scrum

The scrum development team
The scrum team is the heart of any scrum based project. The development team is directly responsible for manufacturing the functionality linked with the particular project. The development activity is carried out by the team members during the iteration or the sprinting activity, which generally lasts for up to two weeks. It is very important for the team members to “jell” with each other, and collaborate, because it is a prerequisite while implementing scrum. The physical location of the team members plays a very important part while the sprint is carried out. In most cases, the entire development activity, and the sprint too, is carried out in a single location, or the same place – under the same roof. However, with the advent of off-shoring and using scrum for complex and extended product development, it may become necessary for the team members to remain located in different geographical locations owing to various reasons.
 

Advantages of having a collocated team
For healthy scrum implementation, high level, and frequent communications are essential between the team members as well as the scrum master while the project is underway. It is generally preferred that the team members are collocated. Collocation means all the team members share a common development location, and even similar infrastructure, during the sprint. There are several advantages of being collocated:

• Questions can get answered quickly and easily
• Problems can be fixed “on the spot” with minimal wastage of time
• Less friction is created in the interactions of the team members
• Trust is availed and rendered much quickly

Means of communications for collocated and distributed teams participating in the sprint 

It is important to communicate in an effective manner to improve collaboration. Several types of tools and methods can be used to improve the collaboration amongst team members.

Collocated teams
- Teams working in and sharing the same office.  Since the team members are located in the same premises the preferred methods of communications can be:
   o Face-to-face
   o Messaging utilities
   o Internal chat tools
- Discussions can also be facilitated using:
   o Meeting rooms
   o Scrum boards
   o Wall displays
   o Shared tables
 
Distributed teams
- Teams placed in different geographic locations.
  Some of the tools recommended for communication purposes are:
   o Video conferencing tools and hardware/software
   o Instant messaging utilities
   o Chatting utilities
   o Social media tools
   o Shared screens
   o Remote access facilities
   o Specialized scrum software which emulate the functionality offered by traditional scrum boards
 

The daily scrum meetings cannot be conducted in a traditional matter since all the team members cannot remain present in the same place owing to geographical distances. In such cases, remotely located team members should participate in the meeting using electronic and online facilities. It is important to set up a fixed meeting time so everyone included in the sprint can participate easily.
 

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

Why Sprint Planning Meetings Are Important While Implementing Scrum Methodology

Sprint planning is perhaps one of the most important aspects of implementing scrum methodology. It offers an opportunity to validate the product backlog and take up user stories for the sprint backlog – the list of requirements taken up by the team members for development purpose during the sprint activity. Sprint planning involves a team effort. The product owner carries out sprint planning with the help of the scrum master, and it requires an active participation by the team members to complete it in a successful manner. The team members divide the user stories taken up in the sprint backlog into individual development tasks. Subsequently, the team members take up tasks for development depending upon their levels of expertise and experience.   

What is the nature of the sprint planning meeting?

The planning meeting generally occurs in two parts – the first part involving the product owner and the scrum master, in addition to the team members. The second part is attended by the team members, who may recall the product owner to the meeting if they need his or her help.

The first part

In the initial part of the meeting, the product owner shares his or her vision regarding what should be included within the sprint backlog based upon the importance of the requirements, or the user stories, available in the product backlog. The person discusses the sprint goal with the team, and explains about what the investors and the stakeholders desire regarding the functionality associated with the product backlog items. The sprint goal is also decided and carefully explained to the team members. One of the most important aspects is the discussion related to the acceptance levels of the user stories i.e. what the user story should satisfy in terms of criteria to be considered as “completed” or “done”. Ideally, the team members should make notes during the meeting so they can remember about the specifics associated with each product backlog item. If any member is unclear about any aspect pertaining to the user story, or how it should be developed, he or she is free to ask during this part of the meeting and get his or her confusions cleared.

The second part

The second part of the meeting is succeeded by a break, usually the lunch break. This part is important for the team members since they have to discuss amongst each other how the sprint backlog items should be segregated and broken down into individual tasks. Each story should be broken down into smaller parts so the team can easily develop it. Thereafter, the individual members of the team unanimously decide as to who should take up which tasks. This part requires a proactive participation, and the members should volunteer to take up work. Generally, the work is taken up based on expertise possessed by the team member. More experienced members can take up more tasks, while less experienced ones tread carefully by taking up easier stories which can be developed without much complexity. Eventually, the list is completed as to which of the user stories will be “processed” and developed by which team member.    

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