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" 

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/

The Product Backlog in A Nutshell: For Scrum Beginners

The Product Backlog

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

Product backlog

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

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

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

Source:- http://www.apsense.com/article/the-product-backlog-in-a-nutshell-for-scrum-beginners.html

Conducting The Daily Scrum Meeting Or The “Daily Stand Up”

The daily scrum or standup meeting

One of the primary responsibilities of the scrum master is to hold the daily scrum meeting, or the “daily stand up”, as it is commonly referred to by scrum professionals. The person is required to get the product owner and the team members together for the meeting. The objective is to avail information pertaining to three important aspects of the daily scrum ^Figure 

1.     Which tasks have been completed in the sprint carried out the day before, or yesterday?

2.     What tasks are to be taken up for development for the particular day, or today?

3.     Did any team member face any hurdles or impediments during the sprint? If so, what were they?

Duration of the daily standup

The daily scrum meeting is time boxed to last for a maximum of 15 minutes, and should not extend this period.

Purpose of the daily scrum

The main purpose of the standup is not to resolve issues or provide solutions to problems. The aim is to apprise the team members regarding the current status of the project, and ensure they collaborate and contribute jointly as a team during the development activity ^{Figure 2}. If any team member faces a problem, and it is mentioned during the daily standup, it is the scrum master’s responsibility to ensure that the issue is resolved at the earliest. The solutions to such problems are provided by the scrum master and the product owner.

Holding stand-ups for non-collocated or distributed teams

One of the major concerns, and also a probable problem at times, for the scrum master is to hold the daily standup when teams are not located in the same office or geographical area. Many companies now use and implement scrum methodology, and in certain cases, the entire development team may not be located in the same place. With off-shoring activities becoming popular by the day, soon it would be common scenario to hold meetings with team members residing in different states and even different countries. Scrum advocates that the daily scrum should include all the team members. In fact, the term “scrum” is akin to the scrum huddle often practiced in rugby, or “rugger”. With large distances separating the team members, it may not be possible to hold a daily scrum in which all team members can be physically present.

A possible way out is to use electronic media and facilities to decrease the geographical distances.Team members can use Skype and videoconferencing tools to participate online in the meeting. The scrum master has to instruct every remotely located team member to log on at a particular time when the daily scrum is to be held, and explain that the members should make sure the hardware and software tools are properly functional at the time of the meeting. 

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

Source:- http://mrugeshpanchal.hubpages.com/hub/Conducting-The-Daily-Scrum-Meeting-Or-The-Daily-Stand-Up

All about Sprints and Sprint Meetings – In a Nutshell

Overview

The sprint is the main point of activity for any scrum project. During a sprint, the development team delivers a certain portion, or a “slice” of the actual development activity to be carried out as defined in the product backlog. During a sprint, the development activity can include a host of other things in addition to the actual development work. This can include the documentation, user manual creation, testing and debugging functionality, or even checking cross platform compatibility. Each activity during the sprint can be understood as a task. When user stories are transferred to a sprint backlog by the product owner, the development team further segregates each user story into its individual tasks i.e. each story is broken down into smaller tasks to make it more manageable and develop able. Each user story is assigned a story point which determines its potential value. The story points help to generate an estimate as to how many user stories can be included in the sprint backlog based upon the team’s ability to carry out the development.

The entire development is carried out in the form of sprints. Usually, a sprint lasts for two weeks, however, technically they can extend up to three to four weeks depending upon how scum is being implemented by the product owner and the scrum master. Sprints are also known as “iterations” in more simple terms. Sprints are supervised by scrum masters. As per the scrum guide, a scrum master should be a passive participant during the sprint. His or her job is to ensure that the team members properly follow scrum rules when the sprint is underway. At the end of the sprint, user stories are developed into shippable products, each with its own functionality and importance. 

 

Sprint planning meeting

A sprint planning meeting is held before the sprint commences. It is attended by the product owner, the team members, and the scrum master. During the sprint planning meeting, the product owner transfers some of the user stories from the product backlog into the sprint backlog for development purposes. The meeting is actually held in two parts:

·       First half of the meeting

During the first half of the meeting, the product owner explains about the user stories which have been included in the sprint backlog. He or she explains about the acceptance levels and the importance of the user stories to the stakeholders. Team members are free to ask questions to the product owner if they require explanations regarding some of the user stories.

·       The second half of the meeting

During second half of the sprint planning meeting, the team members breakdown the user stories in the sprint backlog into smaller, and more manageable tasks, which are taken up for development purposes. Generally, the team members decide unanimously how to distribute the tasks and user stories among themselves. Team members take up work as per their skill sets and development expertise.

Sprint retrospectives

A sprint retrospective meeting is held after the sprint is over. The main purpose of the meeting is to evaluate the sprint which has just completed, and what lessons should be learnt from it. A lot of discussion occurs during the meeting, and both the product owner and the scrum master try to envision what could possible go wrong in the future sprints. They contribute their expertise as well as their experience, and try to identify impediments, and seek solutions for potential problems which may occur in the near future.  

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

Source:- http://storify.com/quickscrum/all-about-sprints-and-sprint-meetings-in-a-nutshel

How Can Scrum Masters Deliver Successful Scrum Projects? Which Characteristics Make A “Good” Scrum Master?

When any organization plans to implement scrum methodology, it first decides about two individuals who play a crucial part in scrum implementation – the product owner and the scrum master. While the role of the product owner is more or less adjudged by the principles and guidelines specified in the scrum guide, it is the scrum master’s role which needs to be decided upon, as to which person can best satisfy the requirements of a scrum master. Generally, people taking up the role of a scrum master belong to a managerial class. It is generally believed that managerial personnel have the experience required to handle teams successfully and come up with positive results. However, this is not always the case, and non-managerial individuals can also take up the responsibilities if they are properly trained for it, and have the potential to deliver positive results. Ideally, the main question asked by the management and the stakeholders should be “Which person can best act as a scrum master and deliver results while supporting the inherent principles of scrum?” rather than ”Which scrum master can function as an ideal manager and deliver the results out of scrum implementation?” It is a fact most scrum master struggle while handling their teams when they start with their careers. Being a scrum master is not an easy task. It is important for a scrum master to follow some principles other than those laid down by scrum to win people and successfully deliver the project. Scrum is all about sharing and collaboration. It is important to know what the scrum master can do to be effective.

1.    Work on a single project

There is a Russian proverb which says if you chase two rabbits simultaneously, you will succeed in catching neither of them. If you are required to handle two projects simultaneously, and if you are putting in one hundred percent towards your work, in reality you are contributing only fifty percent to each project. It means you are not doing hundred percent justice to your projects. This is an important point which every scrum master should know and follow. Working on a single project would mean that you remain dedicated to only one project, and you can put in cent percent of your efforts in the project. One of the reasons why scrum master handle multiple projects is they fear if one of the project fails to deliver or work out, they can still successfully complete the other one, and somewhat save their reputation as successful scrum masters. Successful scrum master get invited to handle new projects, not failed ones. It is important to have confidence in one’s ability to succeed, and put in everything to make the project a distinct success.

2.    Focus upon improving the team effectiveness

Scrum is about teamwork. Scrum framework promotes overall participation and contribution of all team members rather than individual contributions from team members. When scrum is implemented, it creates transparency. Members are supposed to act together as a team and deliver the results out of collaborative efforts. This is what scrum advocates. For a successful implementation of scrum, it is very important for team members to collaborate and share their findings with others. When people start focusing upon individual efforts and contributions, the “we” attitude is replaced by “I” attitude, and the person stops communicating his or her findings to others, and desires to take the credit for the development carried out. This is where scum would fail. Scrum does not require contribution from one particular “individual”, rather it desires an overall output from the entire team. Scrum masters should ensure the team members ought to collaborate and contribute in a collective manner, and should focus upon improving the team effectiveness to function as a whole unit.  

3.    Facilitate rather than manage

Traditional managers and scrum master who believe in delegating their authority to a great extent may find it difficult to mould their thoughts and behavior to suit the role of an ideal scrum master. Scrum is based upon the principles of self-organization and team collaboration. One of the best ways to achieve this is to “facilitate” rather than “manage” the teams in what they do.  A few pointers my help you decide what to do and what to avoid:

What should be avoided:

-        Avoid taking decisions on behalf of the team members

-        Avoid assigning work directly to the team members

-        Avoid tracking individual team member’s performance

-        Avoid taking credit for the work done by the team

-        Avoid engaging the team during status meetings

What should be done:

-        Aid in removing the impediments

-        Set up special one-on-one mentoring sessions for each team member

-        Provide suggestions and inputs regarding how to improve upon the features

-        Participate in a collective manner while hiring additional or new team members

-        Help each team member to plan about career development activities

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

Source:- http://storify.com/quickscrum/how-can-scrum-masters-deliver-successful-scrum-pro

Discover What Is Scrum Methodology and How It Works

At times, projects can be very big. You need a lot of patience while dealing with extremely big projects or highly complex ones. Even experienced project managers tend to get discouraged and start losing hope when the project keeps on extending beyond the deadline, or when things start going wrong with the project. Usually, the management and stakeholders tend to exert undue pressure to the project manager and the development team to perform, and deliver the project, well within the time frame. Projects have a certain financial liability associated with them,   so the sooner the project is completed, the quicker the returns are availed from it. During times when things do not go as per plans, managers start losing hope, and at times wonder if there is a better way of doing things and completing the projects in time so they don’t cost anything extra to the management in terms of increased overheads or reduced returns over investment. This is where scrum comes in – it offers an opportunity to develop your project in a manner such that the stakeholders remain in touch with what is happening to their project, what is proceeding as per plans, and what needs to be removed or done away with so the project can get completed in time and they can start benefiting from the investment they have carried out in the project.

What does scrum methodology offer?

Scrum framework was originally envisioned and developed to be flexible in nature and possess the capability to adapt itself to the changing development requirements. If during the course of the development, if the stakeholders change their minds regarding the project, or desire to change their project related requirements, the situation can be handled in a more beneficial and cost effective way using scrum methodology. Scrum is synonymous with Agile. Scrum, or Agile framework offers an opportunity to make amendments in the project definition while the project is underway. This is a unique feature, since most development methodologies such as the waterfall, which supports a linear structure for development, have no answer or solutions which can effectively cater to changing project requirements. Moreover, a project can be modified to include additional or new functionality when it is underway. If the client decides that a project should offer some features which have not been thought of before, or thought about during the project planning stage, scrum can incorporate these requirements within the development plan. On the other hand, if the project owner feels that some of the features offered by the product may fail to score in the market when the product is launched, those specific features can be easily removed and replace by new ones. Scrum focuses upon development at a micro level. The development activity is implemented and controlled at a very low level, where it is possible to interact with the basic components which constitute to form the project as a whole. It is always much easier to deal with smaller things and change them when they are small in size, rather than wait for them to attain a big size when managing them becomes very complex, and impossible.        

How does scrum work?

It would take a very long time to discuss in depth exactly how scrum operates and what its technicalities are. However, its main features and the method of working can be summarized as:

·       Unlike traditional waterfall methods, scrum does not start with the entire development activity at a go. Rather it breaks up the entire project into smaller functional parts known as user stories, and creates a product backlog which is a kind of master list which includes everything needed to develop the project in totality. Product backlogs contain user stories.

·       Once the product backlog is created by the product owner, a person who represents the interests of the investors or stakeholders, a portion of the backlog is extracted and transferred to a temporary development list known as a sprint backlog. This list contains all the tasks which are to be developed by the team members.

·       Once the sprint backlog is created, the team members distribute the list items or user stories among the developers based upon their levels of expertise. Thereafter the actual development starts. Development is carried out in short bursts known as “sprints”. Each sprint can last from one week up to a month. 

·       At the end of the sprint, a meeting is held to evaluate the outcome of the sprint. Completed items are accepted as “Done” while unfinished ones may be transferred back to the product backlog.

·       The entire process keeps on repeating until all the user stories in the backlog are “Done” and there are no further requirements to be developed.  

Source:- http://storify.com/quickscrum/discover-what-is-scrum-methodology-and-how-it-work

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

What Should the Perfect And Ideal Daily Stand-Up Scrum Meeting Consist Of As Per the Official Scrum Guide?

The daily stand-up scrum meetings play a vital role in ascertaining that the development activity is carried out in a sustained manner. The meetings are usually time boxed to 5–15 minutes and are held standing up to remind people to keep the meeting short and to-the-point. Stand-up scrum meetings also help to find potential pitfalls experienced during ongoing sprints. It is important to know how the daily meetings are carried out, and what they should ideally consist of. On the basis of official scrum guide specified by Jeff Sutherland and Ken Schwaber, the originators of scrum methodology, the article tries to explain in details about the daily scrum meetings.

·       Who should attend the meeting?

Everyone associated with the scrum project should attend the meeting. It is important for the scrum master and the team members to remain present, while the product owner and stakeholders too can remain present if they desire to do so.

·       What should be discussed during the meeting?

It is very important to remain focused and only discus about those topics which are directly related and associated with the sprint activity. The attendees should try not to wander off the main topic and discus about other trivia which are not pertaining to the scrum activity. In fact, the guide is specific about discussing topics which are directly connected to the sprint to be carried out during the particular day, even other topics dealing with the project, or project related issues should be avoided during the stand-up meetings. There are special provisions like the sprint retrospective meeting to discuss about such issues.The main topics to be included during the meeting should consist of:

-        What tasks were accomplished during the sprint carried out the day before?

-        Which tasks are to be developed today?

-        Did the particular team member face any problems or impediments during the sprint implementation? If so, what were they?

  

·       In what order should the discussions be carried out?

There is a lot of flexibility while deciding about the order in which the discussions can be carried out during the meeting. Team members can take turns in discussing about what they have achieved, and what they plan to do on the particular day. Alternatively, the scrum master may decide who should speak first and which team member should follow the discussion. A popular method is to take up discussions regarding important tasks first, followed by the order of priority. The order of discussion can vary from project to project, and from need to need. 

·       Where and when should the meetings be held?

The stand up meetings should be ideally held at the place of work, and in front of the task board. While they can be conducted almost everywhere, including conference rooms, holding the meetings in the actual place of work can help the team members to remain more focused and target oriented. The meetings should be held before the daily sprint is initiated.

·       How to sustain the energy levels during the meetings?

The stand up meetings are also commonly referred to as “huddles” by many people, simply because each team member stands very close to the next one during the meeting. The scene is much similar to the scrum used in rugby. The proximity often encourages the team members to become proactively involved in the discussion. The energy levels start rising up as each team member briefly, and professionally, discusses and outlines his or her activity for that particular day. The meeting is to be held in such a manner that the “atmosphere” becomes charged up with anticipation, and each member focuses upon the goals he or she plans to achieve during the sprint carried out that day.

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

Source:- http://storify.com/quickscrum/what-should-the-perfect-and-ideal-daily-stand-up-s

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

Scrum framework and sprint

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

Can a sprint be terminated abnormally before it is completed?

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

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

·       The stakeholders or the company management changes its priority regarding the product development

·       Market trends and/or changes make the current product development redundant or obsolete

·       A major technology change may introduce newer ways and methods of working

·       A better technical solution may offer a quicker and a more cost effective way of meeting the product development  

·       The management or the stakeholders may experience a financial crisis, or may not be able to financially support the development work

·       The launch of a new or better product may render the current development work superfluous and unnecessary

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

Source:-http://scrummethodology.zohosites.com/blogs/post/In-Scrum-Can-A-Sprint-Be-Cancelled-If-So-When/

What Is Sprint Planning And What Do The Sprint Planning Meetings Actually Consist Of Or Include?

The primary objective of a sprint planning meeting is to discuss and plan about what the development team intends to build or develop in the upcoming sprint, and how the individual members of the team are prepared to go about with their development activity. Though most experts refer it to as a “single” meeting, it is in fact segregated into two unique parts. The first part concentrates upon what the team is actually asked to build or develop, and is attended by the team members as well as the product owner. The second part of the meeting focuses upon how the team members will proceed with the actual development work. The team members are to mandatorily attend both the parts of the meeting, while the product owner is committed to attending the first part only. He or she can however attend the second part if he or she wishes to do so.   

The first part of the sprint planning meeting

During the initial part of the meeting, the product owner has an opportunity to explain in depth about the set of user stories to be developed during the sprint. It is a rapid-fire type of discussion in which the product owner initially explains the user stories, and subsequently the team members start asking questions regarding the points they are not clear about. The product owner has many responsibilities and roles to play. The person represents the client’s interests, explains how the stories are to be linked up in the future, and keep tabs during the entire development activity carried out by the team members. The objective of the meeting is to provide enough information, or brief the team members regarding the development activity required so that each member can carry out his or her part without any confusions or problems.

The questions typically asked during this stage of the meeting are: 

·       What is the acceptance or “passing” criteria of all the stories?

·       What kind of data sources need to be used? Where will the data originate from, and where will it go?

·       How should the developed component look like once it is fully developed?

The second part of the sprint planning meeting

During the second part of the meeting, the team further analyses the user stories and focuses upon creating the sprint backlog which includes the user stories, or the set of requirements and functionality to be developed by the team members during the sprint. The team typically segregates the user stories into individual tasks, and links up, or associates each task with a certain time scale i.e. the duration in which the particular task is to be developed. Generally the tasks are planned to be completed on an hourly basis, however, the time period can be more depending upon the complexity and the levels of functionality to be incorporated into the given task. Another main objective of this part of the meeting is to accept the user stories as practical and “doable”, and to reject those stories which cannot be catered to, owning to various reasons.

The duration of the entire sprint planning meeting can range from two hours up to eight hours depending upon the number of user stories involved, and the levels of complexity. The rule of the thumb is to spend one hour of discussion for each week of sprint.    

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