The Core Role and Responsibilities of a Product Owner in Scrum

One of the commonest mistakes that people make while considering the product owner’s role in scrum is to consider him or her as either actually owning the product, or functioning as a decision maker while developing the product for the stakeholders. This is far from true, since the product owner is actually employed by the stakeholders to represent their interests while scrum is implemented in a project. A product owner can own a product, but is not necessarily its owner in most cases.

The core job of the product owner, or rather the main responsibility, is to:

·       Figure out how to “make” the product

·       Ensure that the sprints are successfully completed during the project

·       Shippable products are delivered at the end of sprints

·       Ensure that the scrum project is successfully completed

The product owner’s job is a difficult one, and a full-time one.

The product owner as the core determinant of a successfully completed scrum project

It is essential to deliver value, and the scrum method requires an efficient, reliable, and an accurate mechanism, which can help to determine the product vision and create an effective pipeline which has the capability of distilling the product vision into shippable, concrete, and deliverable product backlog items that can successfully demonstrate the tangible benefits as a part of the longer project vision. It is because of this reason that the role of a product owner becomes a very important one while implementing scrum.

While the product owner can participate in each Scrum ritual, his or her main function, parallel to that of the scrum master, is to act as a facilitator for the entire team, and be available when problems and issues arise in the project. The main tasks of a product owner are:

·       Envisioning the product and facilitating its development

·       Creating an iterative or sprint release strategy which can incorporate the changing market conditions and product requirements

·       Distilling the high-level product related requirements into developable and deliverable user stories linked with acceptance criteria

·       Prioritizing the product backlog

·       Communicating difficult and complex system architecture issues to the clients

·       Negotiating all client-sided disputes and concerns associated with the product design, development, and user story priorities

Responsibilities of a product owner

The person is mainly responsible for:

·       Representing the interests of, and acting as the voice of stakeholders and customers

·       Understanding project profitability and delivering high ROI

·       Managing the stakeholders

·       Maintaining communications and promoting collaboration amongst the team members

·       Undertaking on-the-spot tactical decisions and ensuring that the product development cycle is not affected

·       Participating in the release meetings and planning

·       Writing effective user stories

·       Maintaining and updating the product backlog

·       Helping the team in estimating the development time for each scrum scenario

·       Participating in the sprint review meetings, accepting the user stories as “Done”, and providing effectual feedback

·       Monitoring the project progress and suggesting constant adjustments based upon important strategic objectives

Source: http://www.informationbible.com/article-the-core-role-and-responsibilities-of-a-product-owner-in-scrum-373803.html

              "Please visit http://www.quickscrum.com to download the Quickscrum tool"

Norms for Holding Effective and Fruitful Scrum Meetings

Many types of meetings are held while scrum is implanted in a project. Right from sprint planning meeting to the sprint review and the sprint retrospective, other non-conventional meetings can also be arranged in scrum as and when needed to fulfill specific objectives.  Following certain norms can help to effective and fruitful meetings.

·       Scheduling the meeting

The best way to schedule a meeting is to consider all the information that needs to be conveyed during the meeting, and assign a proper time and duration for it. Do not try to cram in too many topics so that enough time is not allotted for discussing each topic during the meeting. Ideally, the meeting should last for approximately 30 minutes, so work out an agenda that fits into the time schedule. If the topics to be discussed are more, hold a separate meeting to discuss them. This is very important, since the team members need time to absorb the discussion, and remain perceptive to the plan of action decided for each topic in the agenda at the end of the meeting.

The time to hold the meeting should be properly selected too. Choose the time, which is most convenient to all. Ideally, the meeting should be held around 9 AM when everyone is fresh and about to start their day, or if that is not possible, than around 3 PM when everyone has taken the lunch and people are not feeling groggy immediately after having it.

·       Members attending the meeting

Work out the list of attendees who are going to remain present for the meeting. It is mandatory for the product owner and the scrum master to attend the meeting since they play a center role in scrum implementation. Invite only those members who are associated with the topics included in the agenda, and who need to carry out some plan of action based upon the discussions carried out during the meeting. Other members, who are not concerned, or who have no connection with the agenda topics should not be invited so the meeting place is not cluttered up with too many individuals. When the members are less, it becomes possible to have one-to-one discussion, which is more meaningful and effective.

·       Creating and distributing the agenda

Make sure that a proper agenda is created that includes all-important topics. Once the agenda is prepared, send it, or distribute to the concerned individuals well in time so they have enough time to prepare for the meeting. Each attendee should prepare a list of queries or issues concerning his or her work, and present it to the audience during the meeting. If the participants are well prepared, it leads to more fruitful and productive meetings.  

·       Conducting the meeting in the proper manner

Start your meeting on time. It is advisable not to wait for participants if they do not make it on time. It is essential to convey a message that the purpose and intent of the meeting is important, and should not be trifled with. The meeting should also not be taken lightly by the attendees. Some organizations even levy a certain penalty if the participants do not show up on time. 

Another aspect is regarding the discussions to be carried out during the meeting – they should be focused and topic centric. Make sure, only those topics relevant to the agenda are discussed, and the meeting is not emphasized with other trivial or non-related discussions. Utilize the meeting time in a productive way.Read more on https://www.apsense.com/article/norms-for-holding-effective-and-fruitful-scrum-meetings.html

          "Please visit http://www.quickscrum.com to download the Quickscrum tool"

All about How To Hold Conventional And Non-Conventional Scrum Meetings

In many ways, scrum is all about meetings. Once the product backlog is created by the product owner, the meetings starts, and keeps on occurring until the entire project is completed. While some of the meetings such as the sprint planning, sprint review, and the sprint retrospective are “planned” meetings, and the scrum guide lays down clear guidelines as to how they should be conducted and what should be availed from them, it may be required to hold special meetings as and when needed to streamline the scrum process. The scrum guide does not mention anything about non-standardized meetings, or those which have been called impromptu. It is important to plan and organize such meetings to make them effective in scrum. 

1.    Meet only if required

First and foremost, if the information can be conveyed through a memo, emails, or a small presentation, don’t conduct the meeting. One of the key management strategies is to identify the nature and requirement of conveying the information to team members. If the nature of information is “simplex” i.e. information needs to be conveyed only “one way”, a lot of time can be saved by just sending a memo. Typically, the scrum master or the product owner may need to brief up the team members regarding the feedback availed from the stakeholders, or just let the team know about the time a particular meeting is scheduled. In such instances, it is not required to hold a special meeting to convey “one way” information since a feedback or further discussion is not expected or required with respect to the message conveyed.

2.    Set up clear objectives for the meeting

If a meeting is supposed to be held, it should have an objective! It is meaningless to conduct meetings where objectives are not clearly explained and the team does not have any idea why the meeting is called for, or what is planned to be done in the meeting. A proper agenda should be created beforehand and conveyed to the team well in advance so the team knows why the meeting has been called, and what is going to be discussed in it. 

3.    Instruct the members to prepare for the meeting

If you find it necessary to hold the meeting, and have prepared an agenda to explain what you plan to discuss in the meeting, it is recommended you instruct or inform the team members how they ought to prepare for the meeting. Ideally, a list should be prepared explaining what is expected from the team member, and what activities the particular member should carry out before attending the meeting. If you have team members belonging to specific groups depending upon their area of work and specialization, you could prepare a common list of instructions stating what and how each member in the group should do to ensure their participation in the meeting is a positive one. 

4.    Prepare a plan of action

Now that you have done everything to make your meeting a successful one, it is important you achieve the objective of holding your meeting in the first place. It is important to inform the team members what they are expected to do once the meeting is completed. More than often, people attend meetings and simply forget about what was discussed and whether the objective of holding the meeting was satisfied once the meeting is over. The reason why this happens is there is no “Call-to-action” linked with the particular meeting. Each member should know that he or she is supposed to do to complement the meeting, and ensure its objectives are properly fulfilled.Read more on https://www.apsense.com/article/all-about-how-to-hold-conventional-and-nonconventional-scrum-meetings.html

 "Please visit http://www.quickscrum.com to download the Quickscrum tool"

Means Of Communications For Collocated And Distributed Teams While Implementing Scrum

The scrum development team

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

Advantages of having a collocated team

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

·       Questions can get answered quickly and easily

·       Problems can be fixed “on the spot” with minimal wastage of time

·       Less friction is created in the interactions of the team members

·       Trust is availed and rendered much quickly

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

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

·       Collocated teams

­   Teams working in and sharing the same office.

Since the team members are located in the same premises the preferred methods of communications can be:

o   Face-to-face

o   Messaging utilities

o   Internal chat tools

Discussions can also be facilitated using:

o   Meeting rooms

o   Scrum boards

o   Wall displays

o   Shared tables

·       Distributed teams

­   Teams placed in different geographic locations.

Some of the tools recommended for communication purposes are:

o   Video conferencing tools and hardware/software

o   Instant messaging utilities

o   Chatting utilities

o   Social media tools

o   Shared screens

o   Remote access facilities

o   Specialized scrum software which emulate the functionality offered by traditional scrum boards 

Read more on http://blog.quickscrum.com/post/2014/02/28/Means-Of-Communications-For-Collocated-And-Distributed-Teams-While-Implementing-Scrum.aspx 

          "Please visit http://www.quickscrum.com to download the Quickscrum tool"

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.

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.

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.Read more on http://blog.quickscrum.com/post/2014/03/06/Types-Of-Burn-Down-Charts-In-Scrum-%E2%80%93-What-And-Why-They-Are-Used-For.aspx

          "Please visit http://www.quickscrum.com to download the Quickscrum tool"

Advantages Offered By Scrum Methodology – Scrum Benefits Explained For Scrum Beginners

The scrum methodology

The usage of the word “Scrum” is inspired by a Rugby game technique where individual team members form a group, and collaborate to fulfill a common objective – sprinting with the ball in hand, and covering a certain distance to “achieve” a touchdown. The concept used in scrum methodology is quite similar to the “scrum” used in Rugby. Just as Rugby players huddle together and make efforts to gain the possession of the ball so they can undertake the sprint to achieve a touchdown, in scrum, the individual team members too work in unison, and collaborate to develop a shippable product in short bursts of developmental activity known as “sprints”. Sprints are typically short and target oriented in nature, just as they are in Rugby. Generally, a scrum development team may consist of six to seven members working together under a common roof, or in certain cases, they may be located in different geographic locations. 

Initially, the main purpose of the scrum framework was to develop and manage software-based projects. However, over the years the pioneers who originally designed the framework put in efforts so the methodology could evolve to suit non-IT or software based projects. However, implementing scrum for non-IT based projects, and the fulfillment of project goals requires specialized training, the same case as in software-based projects. It is very important to understand that scrum is a concept – a methodology – and it needs to be enforced or implemented in a well-planned and organized manner for it to be effective.

The scrum team is headed by a product owner who represents the stakeholders and their interests while executing the project, and is accompanied by a scrum master who oversees that scrum is properly implanted at all times while the project is underway. The scrum development team carries out the project development in short bursts of iterations known as “sprints”. The development team is typically composed of trained professionals, who have specialized in a variety of IT disciplines. They can be software developers or programmers, software engineers, Q/A specialists, and individuals who have specialized in other branches belonging to the IT segment.

Advantages of scrum

Scrum framework offers many advantages not found in traditional waterfall development methodologies:

·       Responding to the market changes

Perhaps one of the major factors which often affect, and which may also result into an abnormal termination of an ongoing project is the changes occurring in the market while the project development is underway. Quite often, a project may start successfully and proceed as per plan, but a subsequent release of more effective and functional product may render the current object obsolete and useless. This has happened many a times in the IT market, and many IT companies have suffered heavy losses, and even closed down prematurely. With scrum, it becomes easy to incorporate the changes occurring in the market. New changes can be easily introduced in the project life cycle, and existing development can be modified or “upgraded” to become more effectual and meaningful. In all, scrum helps to incorporate the changes occurring in the market related conditions as and when they occur in an easy and effective manner.

·       Increasing the ROI

Generally, when development is undertaken to manufacture a particular product, it is usually found that approximately 60% of the features associated with the product are rarely, or never really used. However, their development is still carried out simply because they “are there” and were planned to be developed when the project was intercepted. A lot of time, efforts, and cost are involved in developing the features and functionality linked with a product. If the functionality is not really useful, the efforts and cost involved in developing the feature is wasted since it may not have a business value attached to it. Scrum makes it possible to identify such features, and curtail their development, which makes it very convenient for the management to save money and human resources. In scrum, the business value associated with the features is easily identifiable, and their development can be regulated in a much better way as compared to other development methodologies. The investment returns are substantially increased if scrum is used.

·       Continuously improvising upon the project development process

Scrum supports continuous improvement in each project related aspect while the development activity is carried out. The framework is specially designed to identify problematic issues and resolve them as and when they occur. A built in “mechanism” constantly helps to monitor what is currently going on, and which of the issues are holding the organization back in delivering the desired outputs. This is an inherent feature of scrum.Read more on http://blog.quickscrum.com/post/2014/03/18/Advantages-Offered-By-Scrum-Methodology-%E2%80%93-Scrum-Benefits-Explained-For-Scrum-Beginners.aspx  

              "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

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. 

1.    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”. 

2.    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.

3.    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.

4.    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.

5.    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.

        Read more on http://blog.quickscrum.com/post/2014/03/19/The-Main-Reasons-Why-Work-Is-Not-%E2%80%9CDone%E2%80%9D-In-Scrum-And-Why-The-Acceptance-Criteria-Is-Not-Met.aspx

                        "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

Dual Roles Of A Product Owner – The Stakeholders And The Team, How To Balance Them?

A product owner has several responsibilities, and is required to focus upon the two main aspects associated with scrum – the end users, market conditions, and the stakeholders on one hand, and the scrum team on the other. It is not an easy job to carry out. Quite often, the product owner may be faced with a dilemma while carrying out his or her responsibilities on behalf of the stakeholders, and convincing the team members to perform, and act in their interests. It can be a challenging position indeed.     

The outward view: Users, customers, and stakeholders

The first and the foremost priority for the product owner is to understand the needs of end users and the customers. The basic purpose of having a scrum project is to develop a product which is acceptable to them. The consumers are important for the project since they determine whether the product is going to succeed in the market, and if so, what the ideal product ought to offer. The person may be required to conduct personal and group interviews to understand their needs in depth, and avail a clear vision as to what kind of product they really desire and expect. As is the case, many times different users have their own ideas as to what the end product should typically offer in terms of features and functionality. The product owner is forced to review their expectations and ideas at a macro level and decide the practical aspects concerning the product to be developed. If the users have varying requirements or differing perspectives as to what the product should include, it is eventually up to the product owner to decide which of the aspects discussed are really important and feasible, and which can be incorporated into the project.

The stakeholders are important since they invest into the project. The product owner receives the actual product related requirements from the stakeholders, who also have an idea regarding what the end users want. However, their priorities and perspective is centered upon generating a profit out of the project, and it is up to the product owner to deliver the project – nicely wrapped up and ready for sale. The stakeholders also remunerate the efforts of the entire scrum team including the product owner. It is therefore essential that the product owner complies with their instructions and act in their direct interests.

The product owner has to respond to the questions put forward by the users, customers, and the stakeholders. He or she has to advise them, and maintain a vision that can best convey what is important and profitable to them. 

The inward view: The scrum team – scrum master and the development team

While the stakeholders and the end users are important, the development team and the scrum master too are important to the product owner since they are directly responsible for developing the project. Scrum supports collaboration, and the entire team collaborates with the product owner while scrum is implemented in the project. Needless to say, without their help, it is not possible for the product owner to deliver anything.

In most cases, the product owner acts as a facilitator and ensures the team is properly working at all times. He or she has to remain close to the actual development work, and be available whenever the team faces any problems or issues with the acceptance criteria linked with the user stories, and resolve the issues when they occur. The product owner has certain responsibilities towards them. Apart from being a product owner, the person also acts as their mentor, guide, and a good friend when his or her role so demands. Read more http://computersight.com/programming/dual-roles-of-a-product-owner-the-stakeholders-and-the-team-how-to-balance-them/ 

                  "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

Features Of An Ideal And Effective Product Backlog In Scrum Methodology

In Scrum, Is It Possible To Cancel A Sprint? If So, When?

The scrum framework and importance of sprints

Scrum is primarily about dealing with changing market conditions and introducing changes in the product definition while it is being developed. It is very difficult, and in certain cases impossible, to incorporate changes in the features and functionalists linked with the product while its development is currently underway. Traditional development methods such as waterfall do not offer facilities to change the product features once the development has started, since the entire development occurs in stages and it is not possible to reverse the stages, or “undo” the work carried out, nor it is possible to “pause” the development activities and restart them with new ideals and objectives. Scrum makes this possible because the actual development is carried out in sprints which generally last for two weeks. It is very easy to add on, or update the functionality associated with a particular feature of the product.

In scrum, the project requirements are defined in the form of user stories, or product backlog items, which constitute the product backlog. The user stories are arranged as per their priorities and importance in the backlog, and whenever development is to be carried out, a small portion or a set of the backlog, usually the top portion which is more important and carries a higher business value, is transferred to the sprint backlog. During the sprint, each user story contained within the sprint backlog is taken up for development by the team members. After the sprint is completed, the completed user stories are taken up for verification and adjudged whether they are stoppable, and are bug free.

The main feature of scrum which makes it unique is that it supports development in iterations known as sprints. The framework is specially designed to control the sprint, with its checks and counter checks that help to fulfill the objectives defined in the project. If any new feature or functionality needs to be introduced in the project, it can simply be defined as a user story in the product backlog, and subsequently transferred to the sprint backlog for development. The sprint is the most important activity of scrum, and the framework has laid down many rules regarding how it should be controlled. The rules are mandatory, and should be implemented to get the most out of scrum. 

Is it possible to terminate a sprint abnormally before it completes?

The team members have to complete their development tasks before the sprint ends. It is imperative that the sprint process be time boxed, and completed properly if positive results are to be achieved out of scrum implementation. However, under some rare circumstances, a sprint may be terminated before it can complete its full iteration or cycle. The product owner decides whether the sprint can, or should be terminated. Read more https://www.apsense.com/article/in-scrum-is-it-possible-to-cancel-a-sprint-if-so-when.html

                  "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

The Purpose And Goals Of Carrying Out Product Backlog Refinement In Scrum

The official scrum guide mentions about carrying out routine maintenance activities to update the product backlog, or to carry out the product backlog refinement. The exact time to be invested in the grooming activity depends upon the management, and how scrum is to be implemented in the project. A rule-of-the-thumb followed is to put in approximately 10% of the time utilized during the sprint activity, into the grooming activity. It is important to be clear regarding some of the aspects associated with product backlog refinement.

Purpose and goals of carrying out the refinement

The primary reason why the product backlog should be refined is to update or rebuild the backlog so that it remains consistent with the requirements provided by the stakeholders with regards the new features and functionalities to be included in the project. Another reason is to review existing user stories or product backlog items and decide whether they are still useful or pertinent from the development point of view, and to update the acceptance criterion and the explanation detailed in each PBI.  

It is recommended to use the “DEEP” method - detailed appropriately, estimated, emergent, and properly ordered – while prioritizing the user stories within the backlog. Larger stories or epics should be systematically broken down in to more manageable smaller ones, proper estimation by assigning relevant story points to the PBIs should be carried out,  user stories should be rearranged as per the new priorities,  and the queries regarding the development of user stories during the sprint should be effectively answered by the product owner. Whenever a meeting is planned to refine the PBIs, the objective should be to carry out enough refinement work so that it lasts for at least three future sprints.   

Duration and frequency of the grooming activity

Each activity and meeting is time boxed in scrum. Following the same principle, the product backlog refining or grooming activity should be time boxed too. However, in practice, there is no pre-designated activity or a meeting for planning and carrying out the product backlog refinement activity in the same manner as the sprint planning meeting and the sprint retrospective meeting is held. Backlog grooming is carried out more as a routine activity than anything else in scrum, and the guide does not exactly specify how much time or efforts should be invested in the activity. Perhaps a possible reason could be that the product development and creation of product backlogs vary from project to project, and it is difficult to standardize how the grooming activity should be carried out since the size and nature of the product backlog cannot be adjudged. Read more on http://ezinearticles.com/?The-Purpose-And-Goals-Of-Carrying-Out-Product-Backlog-Refinement-In-Scrum&id=8381136

       "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

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

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

1.    Detailed appropriately

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

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

2.    Estimated

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

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

3.    Emergent

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

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

4.    Prioritized

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

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

                             "Please visit http://www.quickscrum.com to download the Quickscrum tool" 

Source:- http://computersight.com/programming/the-deep-method-used-for-product-backlog-grooming-how-to-prioritize-the-product-backlog-items-in-scrum/

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. Know more on http://ezinearticles.com/?Explanation-Of-Scrum-Burndown-Charts---The-Plotting,-Requirement,-And-Purpose-Of-Burndown-Charts&id=8371905 

          "Please visit http://www.quickscrum.com to download the Quickscrum tool"