The Core Role And Responsibilities Of A Product Owner In Scrum

The primary role of the product owner in scrum is to actually “own” the product and function as a “decision maker” on behalf of the stakeholders and project owners. The PO is employed by the stakeholders to represent their interests while implementing scrum framework in their projects. Contrary to what most people new to scrum believe, 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 responsibilities, are:

• Plan the product release and work out how to “make” the product through consistent product increment
• Ensure that the sprints are successfully completed during the project
• Shippable and “bug free” products are delivered at the end of sprints
• Ensure that the 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 the product value at all times. The scrum “mechanism” requires efficient, reliable, and accurate methods, which can help to support the product vision as envisioned by the stakeholders, and create an effective pipeline having the capability to distil the product vision into shippable, concrete, and deliverable user stories that can successfully demonstrate the tangible benefits of the product. It is the primary reason why the role of a product owner is a very important one while implementing scrum.

While the product owner participates in most scrum rituals, 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 to the team when problems and issues arise. 

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 PO 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 and communicating with the stakeholders
• 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

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

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 certain important aspects while scrum framework is being implemented in the project:

• To think about the end users, market conditions, and the stakeholders on one hand,
• And to represent the scrum team on the other.

It is not an easy job to carry out. Quite often, the product owner may face dilemmas while carrying out the responsibilities on behalf of the stakeholders – to convince the team members to deliver successful product increments, and to act in their best interests. It can be a challenging position indeed.
 

The outward view: Users, customers, and stakeholders

The first and the foremost priority of the product owner is to understand the primary needs of the end users and customers. The basic purpose of having a scrum project and implementing scrum methodology in it is to develop an “acceptable” product. The end users are important for the project since they determine whether the product is going to succeed in the market, and, what the ideal product should really offer to be successful. 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 users have their own ideas as to what the end product should typically offer in terms of features and functionalities. The product owner is forced to review their expectations and ideas at a macro level and ascertain the practical aspects pertaining to the product to be developed. If the users have varying requirements, or differing perspectives, as to what the product should consist of, 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 in the project.
 

The stakeholders are important since they invest into the project. The product owner receives the actual product related requirements from them. However, their priorities and perspective are focused more 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 whenever his or her role so demands. 
 

Balancing the views: Switching the role as per requirement

Even though the role played by a product owner is a difficult one, it is not an impossible. One does not have to be a specially gifted person to tackle both the aspects faced while executing the project. It is essential, and very much required, to balance both the aspects and switch the roles depending upon the situations you face. Flexibility of the thought processes, ability to communicate in an effective manner, and negotiating with people can go a long way in making the work easy as a product owner. The PO is required to keep a firm eye, peruse the market conditions, and handle the stakeholders when his or her role demands. Simultaneously, keeping a humane attitude while interacting with the team members can go a long way in keeping the person popular.
 

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

The Desirable Characteristics Of A Good And Effective Product Owner

The role of a product owner is very important in scrum. Besides representing the client and the stakeholders in the project, the  “PO” also has several responsibilities to fulfill with regards the scrum team and the scrum master. The role is not an easy one. The challenges faced by a PO extend far beyond the capacity of a traditional product manager. Besides being responsible for the project’s success, the PO has to carry out several other activities such as:

• Preparing the product backlog
• Defining the product backlog items
• Working out the sprint releases
• and reviewing the work carried out by the development team.

The person is also responsible for defining the acceptance criteria linked with the user stories, and accepting the work as “Done” during the sprint review meetings. Product owners are often pressed for time, and may face certain difficulties while carrying out their work.

It is worth knowing what makes an ideal product owner. Some of the most important characteristics are mentioned herein.

A visionary and a “Doer”

The individual should have the vision to imagine what the final product should be like, and communicate his or her vision to the entire scrum team. The person should also be a “Doer.” He or she should lead by example and preferably use a servant-leader role while delegating authority. The effort should be made to facilitate the scrum proceedings, rather than to issue orders and wait for the team to fulfill them. The person should be able to capture the ideas regarding the requirements as to how the development should be carried out, in what manner, and collaborate closely with the team to avail proper and useful feedback, and analyze it to make informed decisions. The PO should possess the capability to steer the project in the right direction and forecast its progress from time to time. The individual should also think as an entrepreneur and provide valuable suggestions regarding the product to the stakeholders and the investors. It is important to facilitate creativity, encourage and support new ideas and vision, motivate the team members, and feel comfortable while dealing with the changes in the product definition as and when the stakeholders apprise him or her about new product related requirements to be carried out in the functionality developed till date.

Be a leader and a great team player

While talking about the scrum framework, a good PO should be able to create a vision, articulate it, passionately own it, nurture it, and relentlessly strive to achieve the vision in real life by presenting the product to the stakeholders – exactly as they want it. It is exceedingly important to guide the team and everyone involved with the project, and be ready to make tough decisions when they are called for. Above all, the PO should encourage and promote collaboration as it is the base upon which the scrum methodology operates and delivers the results. It is not recommended for a product owner to dictate decisions and delegate authority in an autocratic manner. Moreover, even though the PO is empowered to make decisions, the person should ideally seek the team’s consensus for all scrum related activities. If possible, the team ought to be involved in the decision making too, although few product owners actually prefer to do it in real life.

A good communicator and an effective negotiator

To be a good product owner, and an effective one, the person should possess the skills necessary to negotiate successfully with the customers, end users, development and engineering teams, marketing and sales executives, service personnel, operations department, and the management. It is also important to be a good communicator and have the ability to explain complex ideas and thoughts in a simple and straightforward manner to people who are not technically sound or who are naive.

Subscribe to the permanent free version of the Quickscrum project management tool to get an idea about how the tool works and what it has to offer.

Norms For Holding Effective And Fruitful Scrum Meetings

There are several scrum events, which need to be conducted, while implementing scrum framework in a project. Apart from holding conventional scrum meetings, the:

• Daily scrum meeting
• Sprint planning meeting
• Sprint review meeting, and the
• Sprint retrospective meeting

many other non-conventional meetings too can be arranged in scrum as and when needed to fulfill specific objectives. Certain norms may help to plan effective and fruitful scrum meetings.

 

Scheduling the meeting

The best way to schedule a meeting is to consider all the information that needs to be conveyed and discussed 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. In scrum, ideally the meetings are time boxed, and therefore should not last for prolonged durations, so it is advisable to work out an agenda that fits within the time schedule. If the topics to be discussed are more, hold a separate meeting to discuss additional topics. 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.

The time to hold the meeting should be properly selected. 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 lunch and people are not feeling too much 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 central role during scrum implementation. Invite only those members who are associated with the topics included in the agenda, and who need to execute 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’s topics should not be invited to prevent the meeting place from being 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 it 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 meetings 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 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 scrum meeting is not emphasized with other trivial or non-related discussions. Utilize the meeting time in a productive way.

Appoint one person specially for taking down the minutes of the meeting. This turns out to be very valuable when the participants require to recollect what was discussed during the meeting at a later stage. Many a times, people remember the plan of action immediately after the meeting is completed, but tend to forget, or may get confused in the succeeding days. The minutes can help to freshen up their memory.

Work out the possible call-to-actions for each topic or subject included in the agenda. The minutes of the meeting should reflect which person is responsible for doing a particular action based upon the topics in the agenda.

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

Certain Rules Which Can Help To Make The Daily Scrum Meeting Highly Effective

The daily scrum meeting, or the daily stand up, as it is commonly referred to by scrum professionals, is an integral part of the daily scrum process. The meeting is held before the sprint begins for the particular day. As per scrum methodology, the daily stand up should be ideally time boxed to 15 minutes – it should not exceed this duration whatever the circumstances may be. The three basic questions to be asked covered during the meeting are:

1. How much work has been completed in the sprint carried out the day before?
2. What work is to be taken up for development today?
3. Are any difficulties or issues faced by the team members?

The stand up should not be used to discuss any other topic, or problem, other than answering these three fundamental questions. It is important to follow this format in a strict manner to get optimum benefits.
 

In practice, many times the stand ups are not conducted in a proper manner, and the meeting fails to fulfill its objectives. The sprint may not be completed successfully, and fail to deliver shippable product at the end of its iteration. Certain reasons are responsible for this, and it is worth knowing how they can be avoided. It is possible to hold effective stand ups if the following rules are observed:
 

Everyone arrives on time
The time factor is important. The meeting should commence exactly on time, and everyone should arrive promptly so undue time is not wasted. The team members should follow proper etiquette and ensure the decorum of the meeting is maintained at all times.
 

Everyone attends the meeting
The scrum master and the development team should attend the meeting mandatorily. The entire team involved in the daily scrum should remain present in the meeting. If a team member fails to show up, or has taken a leave for the day, the scrum master should ensure that someone represents that member – at least for providing the feedback of what work was carried out the day before. Moreover, each member should remain present during the entire meeting – no member should leave it unfinished or “half way”.
 

Collaborate during the meeting
Scrum is all about sharing information and helping each other out. The team should concentrate upon contributing as a “whole” rather than concentrate upon individual contribution. The members should be ready to solve each other’s problems if they possibly can.
 

Each member addresses the entire team and not just the scrum master
A highly common mistake made by many organizations implementing scrum is to conduct the meeting in a manner such that a team member focuses only upon the scrum master, and discusses his or her work while ignoring other team members. This is wrong. A stand up is not to be used for reporting purpose. The objective is to discuss, and include everyone present in the meeting. The person addressing the meeting should include everyone.
 

Discuss the 3 important questions only
As stated above, the meeting should only be used to discuss the three basic questions – What was done yesterday, what is planned for today, and are there any problems? No other topic should be discussed in the meeting.
 

Is the Product Owner present?
The product owner should have an idea regarding how the development is proceeding during the sprint. To get first hand updates, it is important to remain present in the daily meetings. The product owner should make a point to attend the daily scrum.

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

5 Pitfalls To Avoid In The Daily Scrum Or The Daily Stand-Up Meetings - Make Your Daily Sprints Effective And Responsive

In scrum, the daily stand up or the scrum meeting is important since it governs the sprint activity for the particular day. The stand up is an integral part of scrum methodology, and should be conducted in a correct manner to get the most out of the sprint. The main responsibility of the scrum master is to ensure that scrum is implemented properly at each stage of the project implementation, and plays a vital role in conducting the stand up meeting. He or she overlooks the meetings, and makes the team accountable for the work carried out in prior sprints as well as the sprint to be conducted for that particular day. As long as the scrum master remains vigilant and conducts the stand up in the method it is ideally supposed to be conducted, positive results are availed from the sprint and user stories continue to be accepted as “Done” in the sprint review. However, there are times when this does not happen. The tasks taken up for development during the sprint may remain unfinished due to technical reasons, or a majority of the stories may be rejected since they fail to satisfy the acceptance criteria. When or if this happens, it becomes vital to find where the problem lies and how it can be rectified.
 

Some of the common traps, or the pitfalls, which result into incomplete sprints or rejected user stories are mentioned herein.
 

1. Utilizing the stand-up as a general meeting
The format of the stand-up is very specific. Scrum suggests only three aspects should be ideally discussed during the stand up:

1. What, and how much work was completed the day before in the prior sprint
2. What is planned for the particular day or “today”
3. Are any problems or issues faced by the development team? If so, what are they?

The stand up is generally held before the work commences for the particular day, and should be time boxed to a maximum of 15 minutes. The team members and the scrum master should utilize this time wisely, and discus the three questions mentioned above. The team should refrain from, and the scrum master should ensure that no other issues or questions should be discussed during the stand up. 
 

2. Using the stand-up to resolve issues and problems
Sometimes during the stand up meeting, certain points or issues stated by a particular team member can give rise to discussions, which may be pertinent and relevant to the meeting, but which may require further study and analysis to resolve them. Typically, when a team member presents a certain point during the meeting, it may incite other members to discuss the particular point, and the entire time allotted for the stand up could be utilized in analyzing the point. As a result, other members don’t get a chance to provide their feedback since the meeting is time boxed, and additional time is not, and should not, be allotted to extend the meeting.
 

The purpose of the stand-up is not to discuss non-relevant points or issues. Even if the issue stated is relevant, a separate meeting should be organized to discuss and analyze the point. The stand up should not be used to resolve issues and problems, even if they are relevant and important.
 

3. Cancelling the stand-up
If the team is too busy with work, or if most of the tasks have been completed well before time, there is a tendency to avoid the stand up altogether. There is a feeling that the stand up should not be called for since there is nothing important to be discussed – the sprint is proceeding well in advance, there is plenty of time available to complete the remaining work, or it’s not worth attending the meeting because it’s not needed. On the other hand, if there is a lot of pending work and the sprints are not proceeding as per schedule, and lagging behind, the team may be tempted to cancel the meeting and utilize the time for development activity. The day begins directly with the team going to work, rather than being preceded by the stand up.
 

This should not happen under any circumstances. Even when everything is proceeding as per plan, the meeting should still be conducted. If there is not much to discuss, the scrum master can close the meeting early and save time. Whatever the reasons may be, it is imperative to hold the meeting.  
 

4. Keeping the daily scrum on a need to know basis
Many times, the scrum master may feel that it is important not to disturb the team members while they are busy with the development activity during the sprint. The person withholds information passed on by the stakeholders and clients, and decides the information should be conveyed at a later stage when the team is not so busy with work, or when relatively free.
 

This should be avoided at all times. The entire team should be kept in the “loop” and apprised of the new developments or feedback received from the stakeholders as and when they are made available. Scrum supports transparency, and each team member has a right to know about anything concerning the project at all times.
 

5. Preventing the team from communicating directly with the stakeholders
When the team faces an important issue, or if some feedback is required from the stakeholders, the scrum master may decide to pass on the issue to the product owner, who in turn passes the issue to the stakeholders. When a feedback is availed by the product owner, it is made available to the team members. The entire process may sound simple and straightforward, but it does not comply with scrum rules.
 

Ideally, the team members should get a chance to participate in the discussion carried out by the product owner with the stakeholders. Scrum supports transparency for a good reason – when other team members join the discussion, new ideas and different ways of solving the problems are created, and this could lead to better productivity. A lot of value time and resources are saved because the team members can directly ask questions regarding the problem, and receive prompt feedback from the stakeholders. The issue is made clear and a more effective solution can be availed as a result.
 

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

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!

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 functionalities 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 functionalities 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 shippable, and are bug free.
 

The main feature of scrum which makes it unique is that it supports development in iterations known as sprints. The scrum 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.
 

The product owner may terminate the ongoing sprint if:

• The management or the stakeholders change the priority of the user stories taken up for development
• Market trends and changes render the current development as redundant or obsolete
• A technology change may offer newer and more effective ways of working
• A technical solution might offer a faster and more cost effective way of carrying out the product development 
• The management may experience difficult times or a financial crisis, and may not be able to support the development work
• The new product launch may make the current development superfluous and unnecessary

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

Sprint Review Meeting Pitfalls – What Should Be Avoided To Get The Most Out Of Scrum Implementation

The sprint review meeting is held at the end of each sprint. It is very difficult to avail the benefits out of scrum implementation if the review meetings fail to remain effective. It is important to know about certain pitfalls, which can render a review useless and meaningless.
 

Use the review meetings for show casing purposes
Generally, during a sprint review meeting, as per the norm the team members demonstrate the development carried out during the sprint, which has just completed. The tasks and functionalities developed are exhibited to the product owner in the meeting. The PO verifies the tasks developed as to whether they comply with the acceptance criteria and if they are “shippable”. The team is apprised whether the task is accepted as “Done”, or is still incomplete since it does not meet the acceptance criteria as defined in the user story. In many ways, the sprint review is often utilized as a “Show and Tell” meeting, and there is nothing wrong with this. However, if the meeting ends with this activity, it is wrong because the main purpose of the review is not satisfied.
 

The objective of the review is not to focus only upon the items which have been developed during the sprint, and which of them have been accepted as done. It is important to update the product backlog with the items, which have been accepted as done, and transfer those items which have not been developed during the sprint, or which have failed to fulfill the acceptance criteria, to be moved back to the product backlog. It is imperative that the entire review should be conducted in whole, and the product backlog updated appropriately at the end of the meeting.
 

Management and stakeholders “take over” the meeting 

Even though it is not mandatory for the stakeholders and the management to attend the meeting, they can do so if they desire. Scrum supports transparency, and since the stakeholders have invested money into the project, they have a right to know about how the project is proceeding. The review provides an opportunity to find how much development has taken place during the sprint, and how the team is performing. Ideally, the stakeholders should participate as guests and keep a low profile while the meeting is in progress. They should refrain from making comments or participating in an overt manner by asking questions directly to the team members. Moreover, at times the stakeholders tend to focus upon individual team members and keep a track of what they are doing, and how they are performing. This is in antithesis of what scrum advocates. Scrum encourages and promotes team efforts. It is what the team delivers as a whole, which is more important than individual efforts.
 

The product owner should limit the participation of the stakeholders in the meeting so the guests do not overcrowd the meeting place, and the team members have enough room to conduct the meeting. The comfort levels of the team should not be compromised upon. The product owner should also warn the guest to participate in the meeting as passive participants, and not carry out any activity which can disturb the proceedings in any way or manner. Reviews can become meaningless if the management or the stakeholders dominate them.
 

Skipping the sprint review meetings 

There is a general tendency amongst the team members to skip the review meeting if they have failed to complete all the user stories taken up in the sprint backlog, or if they consistently fail to get the user stories accepted as “done” by the product owner. The team believes there is no point in attending the meeting since the user stories are not being accepted.
 

It is important to understand that the purpose of the review is not just to accept or reject the user stories. The main objective is to “review” the performance of the team members and carry out self-correction activity after identifying potential pitfalls. Scrum promotes self-learning, and it is imperative that the team members actively participate in the process and learn lessons from prior sprints so they can auto correct their mistakes. Skipping the reviews can halt the self-correction process, and render the review ineffective.
 

Team members remain absent 

It is very important for the product owner to remain present during the review meeting. In fact, the entire review revolves around the product owner, since the basic purpose of the meeting is to get the user stories accepted or rejected by him or her. Therefore, if the product owner remains absent, and does not attend the meeting, the objective of holding the meeting is defeated.
 

The team members should also remain present in the meeting along with the scrum master. The review offers an opportunity for the team to exhibit its work, and generally each member demonstrates the development carried out. The team members take turns to display their work. As per the norm, each member is supposed to demonstrate his or her development. The review also offers an opportunity to avail the feedback from the product owner regarding the acceptance criteria, and know more about the future user stories to be developed by the team. If the team members remain absent during the meeting, they miss the chance of getting informed about how the future user stories ought to be developed.
 

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

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

The scrum framework

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 incepted. A lot of time, efforts, and cost are involved in developing the features and functionalities 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. 
 

Increasing the quality of the products developed 

In practice, over 50% of the total IT budget is spent on maintenance activities once the product is developed and launched into the market. This happens because the quality of the product, or those of the features offered by the product, is very low or not as per acceptable standards. IT companies tend to compromise upon the quality just to meet the project completion deadline, and this often results into a release of a product that is not properly developed, or which does not fulfill the acceptance criteria for it to be successful in the market. The scrum process emphasizes upon a completely shippable product at the end of the sprint, and the product should be bug free. The most important aspect is that the product should totally satisfy the acceptance criteria before it can be considered as “developed”. Scrum helps to increase the quality standards of the features associated with the product.
 

Maintaining a sustained working pace 

Each activity in scrum is time boxed. It is very important to complete the activity in the time allotted for it. Right from conducting and holding the meetings, to the development work carried out by the team members during the sprint, every activity should occur in a sustained manner, and at a sustained pace. 
 
Subscribe to the permanent free version of the Quickscrum project management tool to get an idea about how the tool works and what it has to offer.

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

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

1. Detailed appropriately  

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

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

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

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

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

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

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

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

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

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

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

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

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

Product Backlog Grooming In Scrum

Duration and frequency of the grooming activity 

Each activity and meeting is time boxed in scrum. Following the same principle, the product backlog refining or grooming activity should be time boxed too. However, in practice, there is no pre-designated activity or a meeting for planning and carrying out the product backlog refinement activity in the same manner as the sprint planning meeting and the sprint retrospective meeting is held. Backlog grooming is carried out more as a routine activity than anything else in scrum, and the guide does not exactly specify how much time or efforts should be invested in the activity. Perhaps a possible reason could be that the product development and creation of product backlogs vary from project to project, and it is difficult to standardize how the grooming activity should be carried out since the size and nature of the product backlog cannot be adjudged.

In practice, ideally time equivalent to 10% of the total time spent during the sprint activity should be allotted for the product refinement. For a two week sprint consisting of a total of 6 working hours per day and 14 sprint days per sprint, the time to be allotted should be approximately 10% of 6 hours x 14 days  = 8.4 hours (10% of 6 hours x 14 days = 84 hours). This could be rounded up to one working day. Since the refinement activity is to be carried out on a consistent basis, investing additional time could lead to decreased productivity and an extended product release date – something that should be avoided.  In actual practice, this rule suffices to a great extent.

 
Who should participate in the grooming activity?
Besides the product owner, the grooming sessions should be attended by the development team members and the scrum master. The stakeholders can participate in the sessions too, but their participation should be a passive one, and they should not volunteer opinions, or try to disturb the sessions in any way or manner. Moreover, the product owner should try to limit their numbers during the sessions so it does not become overcrowded and difficult to hold the meeting.

Maintaining a proper approach
It is important to remain focused, and the product owner should be clear whether a particular product backlog item should be estimated again, or it ought to be detailed in greater depth, and additional explanation provided regarding its acceptance criteria. The team members should remain focused upon understanding the PBIs and if required they should demand explanations regarding the acceptance criteria and how the development should be carried out during the sprint activity.

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