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 Main Reasons Why Work Is Not “Done” In Scrum, And Why The Acceptance Criteria Is Not Met

Perhaps the most important aspect of scrum methodology is the concept of “Done” or meeting the acceptance criteria while developing the tasks. The product owner, who represents the interests of the stakeholders, approves and certifies the acceptance criteria defined in individual user stories, or the product backlog items. It is very much important for the user stories to be accepted as “Done” because in scrum an item can only be considered as “shippable” and “complete” when its “Done” criteria is met. The terminology used to describe “Done” is synonymous with the acceptance criteria in scrum methodology. The words describe the same thing.
 

There are times when the acceptance criterion is not met, and the user stories are not considered as complete. This can be the worst possible scenario as far as conducting the daily sprint is concerned, since the basic objective of the sprint cycle is to meet the acceptance criteria and deliver a shippable product at the end of the iteration. Unaccepted and unfinished user stories reflect unsuccessful sprints and improper implementation of scrum.
 

It is worth knowing about some scenarios, which can result in a condition when the “Done” criterion is not fulfilled in scrum. 
 

Lack of a good cross -functional team 

By “cross functional” we mean a team, or a group of individuals having different areas of specializations, who work in unison to achieve a common objective or a cause. In scrum, if the product is technically complex, or if the functionality associated with the product is varied and extensive, it is essential to have a cross functional team. When individuals with different areas of specializations work together to develop a solution, it becomes very easy to carry out the development activity, since the technical requirements are catered to by developers who have required levels of expertise and can provide clear and concise solutions for a given task or a problem. Queries are resolved in a more successful manner, and in the least amount of time.
 

During the sprint, when or if a team member faces a particular problem, it is possible for other cross-functional team members to contribute their knowledge and skills, and provide a proper solution for the problem in hand. This makes the development work easy, fast, precise, and effective. It is very important, and recommended, for scrum teams to be cross-functional. 
 

Non cross-functional team members may find it exceedingly difficult to find quick solutions when problems arise during the sprint activity. The primary reason why this happens is because they lack the required experience, or do not possess sufficient skill sets to offer effective solutions, which can solve the problem currently impeding further product development. The levels of expertise typically required may include designing, business analysis, development, database designing, testing, and other similar skills. It is essential for the developer to be proficient and very good in his or her work. Failing to have such technically sound team members in the sprint may result in substandard or defective developmental activity. Tasks which are not technically perfect, or which have bugs in them may not be accepted as “Done”. 
 

Unclear or undefined acceptance criteria in the user stories and tasks 

It becomes very hard and almost impossible for the development team to successfully complete the tasks included in the sprint backlog if the meaning of “Done” is not properly explained in the user story, of if the story simply fails to include the acceptance criteria required for its development. Typically, in such cases the team starts working blindly, and often pursues a vision of what the actual “Done” should ideally include in the user story. Rather than the product owner explaining the meaning of “Done”, the team assumes what the “Done” criteria is and starts developing the task based upon their assumptions.
 

This can prove to be a dangerous habit as far as the project is concerned since the entire team starts pursuing unclear and even undefined objectives which have no relevance whatsoever as far as the project is concerned. The result is a lot of “wastage” suffered by the stakeholders and the management in terms of unproductive working hours and human resources.
 

Using outdated or obsolete technologies for development purposes 

Technology keeps on changing continuously. For the team members, it is essential that they remain in touch with the latest development techniques and trends. As it quite the norm, existing technology tends to “phase out” over time, and is replaced by emergent technologies, which are more powerful, dynamic, and effective.
 

Using older technologies may lead to incomplete development, simply because phased out technologies do not have the potential to offer the functionality needed to develop a competitive product. Moreover, the team may find it very hard, or impossible, to meet the acceptance criteria, and not be able to develop the task. At times, the definition of “Done” may not be satisfied by using out dated technologies. Using old engineering practices can lead to undue wastage of development time, and even lead to the development of sub standard products. It is very important to use upcoming and newly emerging technologies to deliver quality products.
 

An overworked development team 

The stakeholders and the management are mainly concerned with marketing the product once its development is completed. Their objective is to launch the product as soon as possible, and benefit from the amount they have invested in the project. They often compel the scrum team to take up more work, or even complete the project well before the decided completion date.
 

This can make the development team to cut corners while completing their sprint tasks. Since the team is forced to work against time, it is going to affect the development and quality of the finished tasks. As enough time is not available to check and verify the acceptance criteria, the team may simply decide to carry out the development and submit their tasks in the sprint review meeting without verifying the acceptance or “Done” criteria. The team fails to perform properly because it is compelled to “deliver more” and it simply lacks the time to check the acceptance criterion.
 

Lack of collaboration and integration activity 

The main essence of scrum is collaboration. Team members should work in a joint manner to achieve common objectives. Scrum methodology also advocates team members to co-operate and help each other when problems arise and solutions are required. Moreover, collaboration is essential when the team is undertaking the sprint. Collaborated efforts lead to a well-organized team and improved productivity.
 

When the team members start working individually and stop collaborating, it leads to a situation where in the tasks are not properly linked up, or integrated in a proper manner, to be effective. Generally, during the sprint, the segregated user stories are developed in the form of tasks, and the tasks have to later integrated to fulfill the acceptance criteria. If the team members are working individually, the tasks cannot be integrated or linked up as specified in the acceptance criteria. The definition of “Done” is therefore not fulfilled.
 

Unfocused sprint planning meetings and product owners uncertain in their thoughts 

Scrum is very clear about what needs to be done, in what manner, and when. There is a clear-cut indication about the project flow and the development cycle as to how they are supposed to function, and what they are set to deliver. During the sprint planning meeting, the product owner transfers a set of user stories or product backlog items into the sprint backlog from the product backlog for development purposes. Once the first half of the meeting is over, the team members segregate the user stories into individual tasks during the second half of the sprint meeting, and distribute the tasks amongst themselves. Subsequently, the sprint is carried out to develop shippable items. This is the normal process flow, and scrum can be successfully implemented if this flow is followed in a preplanned manner.
 

If the product owner starts developing second thought regarding the user stories included in the sprint backlog for development purposes, it can lead to a lot of confusion and disarray, especially if the sprint backlog items are “changed“, or some of the items in the backlog are transferred back to the product backlog and replaced by new ones. The team loses it focus since some of the tasks which have already been completed before cannot be linked up with other ones because other tasks have not been developed yet. The team may have to re-plan the development schedule and may not be so clear about the acceptance criteria associated with the new items included in the backlog. The programmers may fail to fulfill the “Done” criteria because they have not been able to plan for it in an organized manner before the inception of the sprint.
 

Lack of proper planning and mutual disagreement regarding “Done”
One of the perquisites in scrum is to have proper planning amongst the team members. Each individual has a specific role to play while scrum is being implemented in the project. In scrum, everything depends upon planning and group efforts. The sprint planning meeting, sprint review meeting, the sprint retrospective meeting, and the product backlog refinement activity are also carried out as per plans. If scrum activities are not properly planned, it can lead to a disarray of related events, and the development activity may suffer as a result thereof.
 

If the product owner and the team fail to reach to a proper agreement regarding the acceptance criteria mentioned in the user stories, the upcoming sprint may be seriously affected in terms of submitting the deliverables. Since there is no mutual acceptance of the definition of “Done” within the scrum team, the development team may not have a clear objective as to how, and in what manner, the tasks should be developed during the sprint. In fact, the team may not have an objective in the first place when it undertakes the sprint since the meaning of “Done” is not defined mutually or accepted by all involved.
 

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

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!

In Scrum, Can A Sprint Be Cancelled? If So, When?

Scrum framework and sprint

Scrum development is fundamentally about adapting to changes occurring during the product development cycle. Scrum levies a lot of significance to transparency, distribution of work, and incorporating changes even “late during the development stage”. Each individual associated with the implementation and working of the scrum framework is assigned a specific role. The person is strongly advised to perform within the boundaries specified by the role he or she is supposed to play, and not transgress the area of work under any circumstances. In scrum, the product owner too has a specific role to play, and is responsible for creating and maintaining the product backlog. The product owner has the final word while working out the list of requirements needed to develop the product – the user stories – which form the backbone of any product backlog. Each user story is further divided into individual tasks, which are taken up by the team members. These tasks are developed during the sprint activity. A sprint activity or simply the “sprint” is nothing but a “burst” of development activity undertaken by the team members, which generally lasts from two to four weeks as decided by the product owner. At the end of the sprint, a meeting is carried out which analyses how much development work has taken place, or how many user stories are successfully completed by the team members. So in many ways the sprint functions as the main essence, or the “heart” of the scrum process. Sprint plays an integral part in the scrum framework.

Can a sprint be terminated abnormally before it is completed?

Development teams are always instructed to complete their user stories as well as tasks well within the sprint duration. It is very important for the sprint process to be completed if the management is to achieve positive results out of scrum implementation. However, under some unusual or rare circumstances, sometimes sprints need to be “stopped” or terminated before it has a chance to run its full cycle. It is the product owner who decides if the sprint can or should be terminated or not.

Some of the reasons, which may induce the product owner to terminate the ongoing sprint, can be:

• The stakeholders or the company management changes its priority regarding the product development
• Market trends and/or changes make the current product development redundant or obsolete
• A major technology change may introduce newer ways and methods of working
• A better technical solution may offer a quicker and a more cost effective way of meeting the product development  
• The management or the stakeholders may experience a financial crisis, or may not be able to financially support the development work
• The launch of a new or better product may render the current development work superfluous and unnecessary

Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which can help you in implementing scrum framework in your projects!

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!