The DEEP Method Used For Product Backlog Grooming – How To Prioritize The Product Backlog Items In Scrum

It is very important to prioritize the product backlog from time to time so that it remains updated, and “healthy”. The DEEP method used to refine the product backlog items can be understood as follows:
 

1. Detailed appropriately  

User stories to be taken up for development soon should be properly understood and taken up for development in the upcoming sprint. The user stories which are not to be developed on an immediate basis can be mentioned briefly and described with lesser details.

Generally, the user stories or the product backlog items having a higher priority should be developed first, followed by less important ones. The smaller and more detailed user stories, which a have higher business value should be place on the top, followed by those which have lesser business values and priorities. Epics and large user stories should be broken down in to smaller, more manageable ones, and taken up for development in succeeding sprints. If the entire product backlog is to be detailed in each grooming session, it would take too much time, and even after investing it, the priority can change in the subsequent refining sessions. Therefore, it is not advisable to carry out the grooming session in totality, each time the session is conducted. The objective should be to target the most important user stories based upon the feedback availed from the stakeholders and detail them as per the new priority. The PBIs should be shifted up or down in the order, and larger epics can be broken down into smaller stories and reinserted in appropriate places within the backlog as per the need.
 

2. Estimated
Besides containing the product backlog items or user stories, the product backlog is an important and useful scrum planning tool. It should include estimation in terms of story points for each backlog item.

Estimation is possible in scrum when story points representing the degree of importance are associated with each product backlog item. It is very important for the user stories to have a certain business value associated with them when they are included in the product backlog. The product owner works out how the story points should be allotted to each item in the backlog. The story points, or the estimate is very useful in planning future sprints, and while creating the burn down charts while a sprint is currently being executed. It is essential for each user story to have a priority, at least when they are important, and to be taken up for development on an immediate basis.
 

3. Emergent
The product backlog is dynamic in nature and changes with time as the project develops. AS more information is availed, new user stories can be added, existing ones updated and re-prioritized, and redundant ones removed. 

In practice, a product backlog is never static, and will change over time. As more is learned, user stories in the product backlog can be added, updated, or removed depending upon the feedback received from the stakeholders and investors. Moreover, the development team should carry out routine perusal and remain conversant with the product backlog so they find it easy to understand the user stories when they are taken up for development. The members should demand explanations about items not clear to them, and the product owner is supposed to resolve the queries as soon as possible in a satisfactory manner. The product backlog should complement the vision seen by the stakeholders and the product owner, and fulfill the expectations of developing a shippable product which is profitable.
 

4. Prioritized
The product backlog should be properly arranged as per the priority of the user stories, preferably at all times.
 

Although scrum advocates that each item be properly estimated before it can be added to the product backlog, in practice, this seldom happens. When the product backlog is initially planned, the product owner understands that some of the stories need to be developed because they are essential and needed to complement the product, or make it shippable. However, quite often, he or she fails to receive proper feedback from the stakeholders regarding their importance, or receives it at a later time. In such circumstances, the common practice is to include the user story in the backlog, and wait for further information to pour in so a priority can be assigned for the particular story. Scrum methodology advices this should not ideally be done, and information should be availed to prioritize the item before it can be taken up for development.
 

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

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!

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!

How Should Items Be Arranged In A Product Backlog?

The product backlog 

The product backlog contains the set of all user stories required to manufacture the product. It is prepared by the product owner on behalf of the stakeholders who actually “own” the product to be developed. The product owner studies and analyses the product, and works out the user stories based upon the functionality to be included in the product. A user story is a product related requirement in scrum. Many user stories constitute the product, and form the product backlog. It is very important to prioritize the user stories in direct relation to their importance and market value. Scrum methodology can incorporate changes occurring in the product related requirements in a dynamic way. Even when the product is actually being manufactured and sprints are currently underway, the stakeholders can still add on new functionality within the product life cycle, and those additions can be successfully added on to the product. The new functionality have to be added to the product backlog before they can be taken up for development. Moreover, during the sprint planning meeting, the product owner selects a set of user stories from the product backlog, and includes them in the sprint backlog for the actual development to be carried out by the team members.
 

A Product Backlog Containing User Stories In Scrum

The product backlog also contains the description of user stories, and strives to explain in what manner the user stories should be developed during the sprint activity. The backlog can also include information pertaining to the various technicalities pertaining to the functionality associated with a user story, in addition to the functional and non-functional requirements needed to understand the user story in the perfect manner. The product backlog forms the “heart” of scrum methodology, and should be carefully prepared in a proper manner by the product owner.
 

It is worth knowing about the “DEEP” qualities required to create a properly organized and effective product backlog.
 

The “DEEP” qualities of a product backlog
The four major qualities which help to define an ideal product backlog are:

1. Detailed Appropriately
2. Estimated
3. Emergent
4. Prioritized

Detailed appropriately 

All the product backlog items should be appropriately detailed, with the higher priority items listed in the beginning or top of the list and the less important items being displayed in the bottom. As per the scrum guide, the more important the product backlog item, the more information it should include, and the less important the item, lesser details should be provided for the particular item. The backlog should be concise – it should only include information which is absolutely necessary and pertinent. Moreover, it is also required to number the items to avoid any confusion from occurring between similar items.
 

Estimated 

It is important to include the estimation aspect and link it up with the product backlog items so they can become quantifiable. Story points are used to quantify the backlog items so they can be properly prioritized. A story point is a unit of measurement used in scrum to determine the actual “worth” of a user story. Each item should be associated with a certain story point value when it is included in the product backlog.
 

Prioritizing The User Stories According To "DEEP" Qualities

Emergent

The product backlog should be dynamic in nature i.e. it should be able to include new items as and when desired by the stakeholders and the product owner. It should be stable, and not get disturbed when items are added or removed from it. Moreover, it should allow the items to be shifted up or down in the list, and also allow individual modification of details linked with the user stories contained in it.
 

Prioritized 

All the product backlog items should be prioritized. It is also equally important for the product backlog to support re-prioritization of the items once they are indexed within the backlog. This is often required if the nature of the product is volatile and subjected extensively to changing market conditions, in which case the stakeholders might decide to add on new functionality, or change the priority of existing ones depending upon their needs in the market. 
 

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

Explanation Of Scrum Burndown Charts – The Plotting, Requirement, And Purpose Of Burndown Charts

What is a burn down chart?
A burn down chart is an important tool in scrum. It provides a visual representation about the progress achieved in a sprint while it is underway. They are very common and extensively used by scrum masters while scrum is being implemented in a project. The quantity, or the amount of work remaining, in the form of pending tasks, is typically exhibited in a burn down chart. The chart is simple and easy to understand, even by people who are not familiar with scrum methodology. Burn down charts are very useful for estimation purposes, and are essential for determining the sprint velocity – the rate at which work in the form of user stories is being completed by the development team – and planning the sprint release.
 

Plotting the burn down chart
A burn down chart can be plotted by including the work remaining in the form of story points along the vertical Y-axis and the working days along the horizontal X-axis. The pending work is typically represented in story points – a unit of measurement to calculate the importance and priority of user stories in the sprint backlog – instead of user stories. The reason is user stories are broken down into tasks during the second half of the sprint planning meeting by the development team. It becomes difficult to read and understand the chart if tasks are represented along the Y-axis. User stories are descriptive in nature, and do not have a number or a value associated with them, so it becomes difficult to estimate them. Therefore, the story points, which are numeric values associated with each user story, are used for plotting purposes.
 

On the first day of the sprint, the total number of days completed in the sprint is zero while the pending work constitutes of the entire sprint backlog. Conversely, when the entire sprint is processed, the number of days is equivalent to the days the sprint has actually lasted – generally two weeks – and the pending work should be zero. The burn down chart can include an “ideal” working line, which originates from the top left-hand-side corner of the graph where the number of days is equivalent to zero along the X-axis and the story points are maximum on the Y-axis. The ideal line extends or runs diagonally, and connects to the bottom right-hand-side of the graph, on the X-axis where the days are maximum i.e. equal to the total number of days the sprint lasts. The story points are zero on the Y-axis. The ideal line reflects the desired level of work and sprint completion status.   
 

Starting from day zero, when the story points are maximum, as the sprint progresses, the days increase along the X-axis while the story points start decreasing along the Y-axis. On day one, when some of the user stories are completed, a point is interpolated on the graph which correlated to the first day of the sprint on the X-axis and a value equal to the maximum story points in the sprint minus the value of story points completed on that day. For example, if 25 story points are included in the sprint, and on day one of the sprint if work equal to 5 story points is completed, the total pending work remaining in the sprint is equivalent to 25 – 5 = 20 points. The coordinates of the point would be (0, 20) on the graph. Similarly, on the second day of the sprint, if work equal to 1 story point is completed, the total work remaining is equivalent to 20 – 1 = 19 story points. The coordinates for the second day would be (1, 19) on the graph. Many scrum masters prefer the dates to be displayed along the X-axis in lieu of days to make the chart more readable.
 

Reading the chart
Many burn down charts actually have the “ideal” line plotted on them – for reference and estimation purposes. It is a good visual indication whether the particular sprint is proceeding as per schedule, or whether the development work is carried out behind schedule.  The line represents the ideal “burn down” required for attaining the sprint goal or the ideal position to be in at the end of sprinting day. The actual work carried out is plotted on the graph with the help of coordinate points. All the points plotted on the graph are connected with a line, which passes through them. If the actual line extends above the ideal line, it indicates that the sprint is proceeding behind schedule, and the required number of tasks is not being completed as per the sprint planning. This basically indicates two things – one, the team has to put in more efforts to compensate for the pending work which should be completed the next working day, and two – the team is required to introspect and find out why the tasks were not completed on time. It is important to self-correct and ensure the same mistakes are not repeated since scrum advocates self-learning and self-correction processes.
 

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!

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!

How Do Velocity And Story Points Correlate During Sprint Estimation

How is “velocity” understood in scrum?

The term “velocity” is used to describe the pace, or the rate at which the development team members carry out, and deliver work during sprint activity when scrum methodology is implemented in a project. It is a simple, but power technique to generate a reasonably reliable estimate about what the team is capable of doing, and the rate at which it can deliver completed user stories at the end of the sprint. It is important to know that the stories developed should be totally “complete” and “shippable” to be considered for the estimation. User stories accepted as “done” are included for the velocity calculation in scrum.

Why it is necessary to estimate velocity

Scrum includes a lot of planning, and setting up of goals when it is to be implemented. The product owner prepares a product backlog, which contains the list of user stories or the requirements needed to manufacture the product. Once the list is prepared, the person is required to give an estimation to the investors and stakeholders as to how long the product will take to develop, and when it can be availed for selling purposes. This is when an issue comes in – how can a proper estimate be given regarding the product development? 

In case of traditional development methodologies such as Waterfall, the estimate is generally given by calculating the working hours based upon the productivity delivered by individual team members. In case of scrum this is not possible, since the focus is upon the team as a whole. Individual effort does not count in scrum. It is what the team delivers as a whole unit which is more important. Moreover, team members possess varying levels of expertise. An experienced developer might complete a task in two hours, while a novice or an amateur might complete the same task in eight hours. It further adds on to the complexity of creating a trustworthy estimate.

What are story points in scrum?

To overcome this problem, points known as “story points” are allotted to each user story based upon its level of difficulty. Simple and easy stories carry fewer points while difficult ones carry a higher weightage. A story point is an arbitrary number value assigned to a story to indicate the complexity associated with the functionality linked with the development. In simple words the story point conveys how complex and difficult the particular requirement is. The story point can be an integer, however it can also be fractional depending upon the manner in which the complexity is determined for a particular requirement. For example, an experienced programmer might find a particular task easy, and assign five points to a story. A novice developer might find the task difficult and assign ten points to it. So the user story can be associated with two values depending upon who develops the story – five and ten. This is in contradiction, since the story point should be a unique number. It cannot assume two values. In such scenarios, the scrum master assigns a mean value of the two numbers i.e.

	Story points
Experienced programmer	10
Novice programmer	5
Mean value	[(10 + 5) / 2] (two programmers) = 7.5

      

The story point value for the above example would be 7.5.

How are story points and velocity related?

Once the product backlog is created, the product owner is liable to provide an estimation regarding the project completion. The person starts assigning story points to the user stories contained within the backlog. He or she may also request help or advice from the scrum master as and when required while assigning the points. Once all the stories are linked up with appropriate story points, all the points are added up to form a grand total. This total provides an idea how big or large the entire project is. For example, a project may include user stories which may total three hundred points. It becomes possible to create an estimate once a grand total is available.

Product backlog story points	300 points
Total number of points which can be successfully developed by the entire team during the sprint (Assume or suppose)	30 points / sprint
Therefore, total sprints required to process the product backlog	300 / 30 = 10 sprints
One sprint lasts for	2 weeks
Therefore, 10 sprints can extend for	2 weeks x 10 sprints = 20 weeks

The entire project can be estimated to be completed in 20 weeks time. 

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!