Avoiding Product Backlog Pitfalls – Get The Most Out Of Scrum

The product backlog is the heart of scrum in many ways. All the technical requirements needed to develop the product are included in the form of user stories in the product backlog. It is important that the product backlog item, or the user story, should be properly defined and narrated within the backlog. A product backlog item consists of several types of information, which actually define the exact requirement to be developed by the developed team during the sprint. It is very important that the product owner, the person who defines the user stories in the product backlog, avoid certain pitfalls, which can mess up the readability of the user story, or make it ineffective for development purpose.  
 

Creating the product backlog without any prioritization 

Estimation is an integral part of scrum, and burn down charts are created to reflect the velocity at which the team is currently carrying out the daily sprints. Estimation is possible only if backlog items are prioritized with user stories.
 

Creating the headline and not adding any explanatory description
Adding a title to mention the story name alone does not suffice. The team needs more information regarding the story to be developed.
 

Using less priority levels 

The user stories should include at least three priorities – high, medium, and low. Using only two priority levels such as “urgent” and “Later” fails to give a proper idea to the team as to how important the story is from the development point of view.
 

Committing the release date without prior communication
The team should be initially consulted and a release date worked out before apprising the stakeholders about the date.
 

Creating tasks instead of user stories
During the second half of the sprint planning meeting, the team segregates the user stories into individual tasks. The product owner should not define individual tasks in lieu of user stories in the backlog.
 

Long running sprints
The sprint should ideally last up to two weeks. If the cost effectiveness of product development is to be maintained, the sprint should be properly decided. It should not be too long so that feedback is availed after long intervals, and it should not be too short so that the team does not have enough time to develop the tasks. Both the aspects should be properly balanced.
 

Preparing a limited number of user stories
When the scrum project is planned, the product owner should create the entire product backlog. Creating a few stories to “start” the scrum process defeats the very purpose of implementing scrum, since proper estimation cannot be carried out, and velocity too cannot be determined in an effective manner.
 

Meeting only once a week
The product owner should be available as and when required by the team members and the scrum master. Meeting only once a week can prevent the team from proceeding with the development in case any problems are encountered during the sprint or additional information is required to understand the user story.
 

Answering your phone during the meeting
Perhaps the most irritating aspect is answering cell phones while a meeting is underway. It not only wastes time, but also breaks the concentration levels.
 

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

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!

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!

Types Of Burn Down Charts In Scrum – What And Why They Are Used For

In scrum, a burn down chart is used to provide a graphical representation of the total work remaining, or left to do, versus time. The pending or outstanding work is generally represented along the vertical X-axis, while the time is plotted against the horizontal Y-axis. A “burn down” chart should ideally be understood as a “run down” chart i.e. how much of total work is still pending and needs to be completed. Even though burn down charts are synonymous with Agile framework and scrum methodologies, they can also be used in other non-Agile frameworks. Basically, burn down charts can be used in any project in which the progress can be measured with respect to time.
 

Scrum supports several types of burn down charts, and they can be effectively used to measure the progress right from the macro level. At the project level, burn down charts can be effectively used to estimate and depict the progress made. When the project is segregated into its fundamental components at the product level, and when small sets of requirements in the form of user stories taken up for development at the sprint level, the progress can still be measured using burn down charts – even at the micro level.
 

The charts are explained as follows:
 

Product Burn down Chart
The product backlog, created by the product owner at the onset of the scrum project, forms the backbone of all product related requirements in the project. It is the main list which constitutes the product. As the product items, or the user stories, are taken up for development during the sprint, certain stories in the product backlog get marked as “Done” as the sprints keep on progressing. At the end of each sprint, the items successfully developed by the team are accepted as complete by the product owner and flagged accordingly in the product backlog. Therefore, at any given instance of time, the product backlog can consist of complete or pending items. The chart explaining the pending product items and those that have been completed over time is known as the product burn down chart.
 

The main objective of the product burn down chart is to estimate, and explain to the team as well as the stakeholders, how many more sprints will be required to complete all the user stories defined in the product backlog, and how much time will be required to successfully exhaust the backlog. 
 

Sprint Burn down Chart
During the first half of the sprint planning meeting, the product owner transfers some of the unfinished user stories from the product backlog into the sprint backlog. The stories contained within the sprint backlog are taken up for development by the team members during the daily sprint activity. Each day, as per plan, certain user stories are taken up for development by the programmers, and efforts are made to complete them by the end of the working day, or the “sprint” day. As the sprint proceeds each day, certain stories are completed, while the pending ones start reducing in numbers. The chart, which represents how many user stories have been completed, and ideally how many stories should or ought to be finished each day, while the sprint is underway is known as the sprint burn down chart.
 

The user stories are actually broken down into individual development tasks, and are calculated in terms of ideal working hours. Therefore, in the chart, the tasks are plotted against time, and while the sprint days are represented along the horizontal X-axis, the tasks in terms of ideal hours are plotted along the vertical Y-axis. 

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 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!