Reasons For Carrying Out The Product Backlog Grooming Activity

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

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

 

Product Backlog Grooming In Scrum

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

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

Informal product backlog grooming 

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

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

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

The Product Backlog In A Nutshell: For Scrum Beginners

The product backlog 

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

Product Backlog In Scrum

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

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

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

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!

The Responsibilities Of A Product Owner

As far as scrum methodology is concerned, the product owner plays a very important part in creating new products, and enhancing the value of existing ones for an organization. Many businesses struggle to implement the role in an effective manner, but often fail to do so. There are several reasons why this happens. One of the commonest causes is that the organization fails to properly understand the exact role played by the product owner, or may be unsure as to what kind of role is best suited for their project related requirements. The product owner “owns” the product on behalf of the investors and the stakeholders. The person is responsible for the success of the project, and is answerable to the management for the project.
 

A multifaceted role
The role of a product owner varies in real life depending upon several factors such as the market conditions, product life cycle, and management related concerns. The aims and objectives of a project depend upon the type and nature of the product to be developed, and how the owners desire to manufacture and market the product. The product owner has to oversee the completion of the project, whatever the project related requirements might be. There are times when the person has to think as an owner and ensure the project is being properly executed, so it benefits the management. The person may be required to act as a facilitator and coordinate the working of the team. It may be required to think like an entrepreneur while suggesting project related ROI solutions to the stakeholders. The role is not an easy one, and the product owner required to be a bit of everything – a team leader, entrepreneur, project manager, facilitator, and a product owner! 
 

Responsibilities of the product owner
A product owner should take up certain responsibilities:

People

• Understand the needs of customers and end users
• Collaborate with the development team
• Successfully manage the stakeholders

Strategy

• Create an effective business model
• Working out proper strategies for conducting sprint planning meetings, sprint review meetings, and sprint retrospective meetings 
• Develop the product definition and road map
• Define and explain the user experience and the product features

Learning and delivery

• Set up the sprint goal, detail the user stories, and decide what to do next
• Collect relevant data and analyze it for goal validation
• Update the business model and product features as per need
• Monitor and track the project progress (time and budget)
• Coordinate with the stakeholders for the product launch

Scrum

• Have the correct vision about how and where to take the product
• Prioritize the product backlog as per business value associated with user stories  
• Advise and offer help to the scrum master when asked for or required
• Analyze and understand the business model including the value proposition as well as the business benefits desired from the product development
• Ensure effectual sprint goals are set up and followed
• Choose the correct research and/or validation technique to exhibit the product increment

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

The Role Of A Product Owner

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

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

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

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

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

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

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

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

The Scrum Task Board Explained

The scrum task board
The scrum board is the main object of interest for the entire scrum team, since each activity carried out using scrum methodology is reflected directly or indirectly on the scrum board. It is generally located in the venue where the daily scrum meetings or the daily stand ups are held before the sprint is initiated for the particular day. Scrum boards are the center point of focus for the entire team. The sprint backlog, in the form of story cards, is represented on it. Each day as the sprint progresses, the scrum board reflects the updates of work carried out by the development team. As the user stories develop, the cards are rotated on the board, and provide information to the team as to which particular activity is currently being undertaken and processed. In real time, the scrum board is updated before the sprint commences for the particular day, and it typically exhibits the sprint activity carried out the day before.   
 

Story
The story column displays the list of user stories taken up for development during the sprint. "User stories" is the work accepted by the team during the sprint planning meeting. Each user story is broken down into development tasks, and each task is individually taken up for development by the team member during the sprint.
 

To Do
The column reflects the tasks taken up for immediate development from the sprint backlog. The backlog constitutes the entire work to be completed during the tenure of the sprint – over the coming days. The stories can be picked up on a random basis, or according to a specific plan followed by the team. The “To Do” list is populated by those stories which are to be considered for development on an immediate basis, unlike the entire sprint backlog which is processed in small segments.
 

In Process
This column is populated by those tasks which are currently being developed by the programmers or developers on the particular sprinting day. Ideally, the stories included in the column should be completed on the same day before it ends. However, if the task is complex, or lengthy, the task may be extended over the next day.
 

To Verify
This column includes the stories which have been taken up for development during the sprint, but need some further clarification before they can be taken up for development purposes. Also, when a particular task is taken up for programming and if some issue is found connected with it which prevents further development, the task is transferred to the “Verify” column. The doubts or the issues connected with the story are resolved by taking help from the scrum master or the product owner, and subsequently transferred to the “Story” column or the “To Do” column depending upon the team’s decision when to develop it.
 

Done
The column includes all the tasks which have been completed by the team during the sprint activity. During the sprint review meeting, the tasks included under the “Done” column are verified by the product owner and accepted as “Done” or rejected.
 

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!

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!