Showing posts with label Sprint backlog. Show all posts
Showing posts with label Sprint backlog. Show all posts

Friday 10 October 2014

Scrum Product Owner Role And Sprint Planning Meeting Agenda

In many ways, in a Scrum project, the sprint planning meeting agenda plays a very significant part in determining the success of delivering shippable product increments through the sprint iterative cycles. The product owner is very closely involved in the sprint planning agenda, and is responsible for the outcome of the sprint cycle, since he or she is primarily responsible for taking the initiative and “designing” the sprint – the PO decides which user stories should be ideally taken up for development purposes based upon their business values. Moreover, the product backlog needs to be refined on a regular basis. The PO may invite and seek the help of Agile team members to keep the backlog refined so “granular” and developable user stories are available at the time of Scrum planning meeting.
The main issue with Agile Scrum today is that the role of a PO cannot be “standardised” based upon assumptions as to how Scrum ought to be implemented in a project, and what the PO should ideally do to make the project a distinct success. In addition, while considering Scrum sprint planning, the same thoughts might be applicable to it as those associated with the PO’s – it is difficult to create generalised rules regarding how a sprint should be ideally designed. The primary reason is products and requirements change as per fluctuating market conditions, and stakeholders too are liable to change their thoughts as and when end user demand user-specific requirements and development. However, after considering the fact that scaled Scrum versions are likely to “dominate” the Agile scenario over the coming years, it is worthwhile thinking that “some” of the duties of a PO and certain sprint planning “characteristics” are likely to remain common – irrespective of which scaled version is used, and the manner in which Scrum should be, or can be, implemented in a project. In addition, while the sprint planning meeting was traditionally conducted in two parts, the Scrum event has now evolved to be conducted as a whole – as a single event – and include two topics in it, rather than two parts:
  • What can be done in this (currently being planned) sprint – the “What” aspect
  • How should the chosen “work” be ideally “done” – the “How” aspect
It is interesting to think about how the product owner’s role is likely to modify itself in the future, and what features the sprint planning event is likely to include. The suggestions are open for debate, and the reader is invited to present his or her viewpoints.

Scrum product owner role and responsibilities likely to remain “common”

  • Creation of the product backlog based upon the vision as seen by the stakeholders. Defining user stories having high business values so the project “worth” is maintained at all times.
  • Monitoring all Scrum related activities in project. Even if the PO’s role may be demanding and “difficult to play”, the PO still has to deal with changing market conditions, stakeholders requests, and negotiate with the development team with regards delivering shippable stories and maintaining team velocity... Read more at Scrum Product Owner Role And Sprint Planning Meeting Agenda



Monday 14 July 2014

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

The primary objective of a sprint planningmeeting 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.   

                                   Subscribe Free scrum tool from Quickscrum.com


Thursday 3 April 2014

Why Certain Businesses Fail To Benefit From Scrum – Part 1

Scrum may be difficult to understand and follow
Despite the fact that scrum framework helps to provide solutions for the drawbacks prevailing in traditional project management methodologies, in many cases, the company implementing scrum for the first time may face certain issues associated with scrum itself. Scrum methodology is highly adaptable and powerful. It can cater to changing market conditions, and successfully incorporate the changes within the product development cycle, even while the product is currently being developed. There are several advantages, which makes Agile scrum a much desired development methodology. However, implementing scrum in a successful manner can prove to be very challenging for first timers. The impediments faced are generally related to the transition process, as the company starts migrating from its current development methodology to scrum. For majority of people new to scrum, the environment may appear to be complex, rigid, and difficult to understand and follow. This is a misconception since scrum can be almost everything but not rigid in the truest sense. In the initial stage, the team may find it difficult to understand how scrum works, and what kind of roles the product owner and scrum master play while implementing scrum. In addition, there are certain artifacts or objects such as the product backlog and the sprint backlog which figure prominently in scrum. Moreover, scrum events such as the daily sprint meeting, sprint planning meeting, sprint retrospective meeting, and the sprint review meeting may confuse novices why they exist, or are needed in the first place. Scrum can be quite different when compared to traditional waterfall project development methods, and people often start developing a negative attitude towards it simply because they fail to understand it.   

Not getting the desired results out of scrum implementation
A company or a business may decide to implement scrum to reduce the project turnaround time or increase the productivity and the ROI. There is always a reason why an ongoing process flow may be required to be replaced by a new one by the business owners. The management and stakeholders may have “heard” about the obvious benefits of using scrum, and how their business can possibly benefit from them. The management personnel may have high expectations, and might even plan their marketing goals and objective keeping in mind the benefits availed by implementing scrum in their ongoing projects. However, in many cases, due to various reasons scrum implementation may fail to produce the desired results for the particular business, and the entire project may go askew with no clear indication as to in which direction it is heading for. The reasons may be many and varied. It is important to know what they are if scrum is to be implemented successfully.  

·       Improper communication channels and feedback
Broken feedback channels and improper communication processes primarily lead to a void in the learning process which is so very important while implementing scrum. A major issue is the lack of feedback availed during the scrum meetings and important information not being transmitted to the team members in the correct manner, or at the correct time. In scrum, the entire project is developed in short bursts of development activity called sprints. Sprints are to be conducted on a daily basis. The daily stand up or the daily scrum meeting precedes the sprint activity. Three important questions are to be answered during the meeting. The product increment during the daily sprint can be affected by the answers availed during the stand up. After the entire sprint is over, a sprint review meeting is held to evaluate the development carried out by the team. The product owner and the scrum master evaluate the entire sprint during the review, and efforts are made to generate new findings based upon prior experiences. The findings need to be conveyed to the team.

Result
When the communication channel fails due to some reason and proper feedback is not transmitted to the team members, they may start with a new sprint and repeat the same mistakes they made in the prior sprint. Scrum supports self-learning and self-correction activities which are possible only when a proper communication channel is set in place, and feedback is made available to the entire team. If the team members do not receive any feedback or communications from the concerned personnel, they may proceed with future activities without any definite aim or objective.  This can be disastrous for scrum because everything is planned, and each activity is carefully regulated in scrum. The team members fail to perform in the correct manner and the entire project suffers as a consequence.     

·       Organization lacks sufficient scrum knowledge and experience
Project managers are more used to traditional waterfall methods and are familiar with their process flow. Scrum is very different, and the framework should be understood in depth before it can be used or implemented in any particular way or manner. It is essential that the entire team be educated in scrum and knows how it works. The team members should be well apprised about the importance of the scrum artifacts and the purpose of the meetings. They should be made aware about the importance of sharing information in scrum and collaborating with other team members. At times, the team may not be clear about how a scrum meeting should be ideally conducted, and what information ought to be availed from it. A lack of clear purpose may render the entire meeting as useless. The team members may fail to deliver productivity in a scheduled or effective manner. The entire scrum process could be hampered.Read more on http://blog.quickscrum.com/post/2014/03/31/Why-Certain-Businesses-Fail-To-Benefit-From-Scrum-%E2%80%93-Part-1.aspx

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


Tuesday 25 March 2014

The Main Reasons Why Work Is Not “Done” In Scrum, And Why the Acceptance Criteria Is Not Met

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Thursday 20 March 2014

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" 

Friday 14 March 2014

Explanation Of Scrum Burndown Charts – The Plotting, Requirement, And Purpose Of Burndown Charts

What is a burn down chart?


A burn down chart is an important tool in scrum. It provides a visual representation about the progress achieved in a sprint while it is underway. They are very common and extensively used by scrum masters while scrum is being implemented in a project. The quantity, or the amount of work remaining, in the form of pending tasks, is typically exhibited in a burn down chart. The chart is simple and easy to understand, even by people who are not familiar with scrum methodology. Burn down charts are very useful for estimation purposes, and are essential for determining the sprint velocity – the rate at which work in the form of user stories is being completed by the development team – and planning the sprint release.  

Plotting the burn down chart
A burn down chart can be plotted by including the work remaining in the form of story points along the vertical Y-axis and the working days along the horizontal X-axis. The pending work is typically represented in story points – a unit of measurement to calculate the importance and priority of user stories in the sprint backlog – instead of user stories. The reason is user stories are broken down into tasks during the second half of the sprint planning meeting by the development team. It becomes difficult to read and understand the chart if tasks are represented along the Y-axis. User stories are descriptive in nature, and do not have a number or a value associated with them, so it becomes difficult to estimate them. Therefore, the story points, which are numeric values associated with each user story, are used for plotting purposes. Know more on http://ezinearticles.com/?Explanation-Of-Scrum-Burndown-Charts---The-Plotting,-Requirement,-And-Purpose-Of-Burndown-Charts&id=8371905 

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

Wednesday 26 February 2014

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.  


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

Thursday 20 February 2014

The True Explanation of How Scrum Iterations Or Sprints Can Help To Support And Incorporate Dynamic Changing Environments

Scrum and iterative development
Scrum framework actively supports project development in the form of iterations, known popularly as “iterative development” in technical jargon. Scrum supports iterative development in the form of sprints. The feature helps to control the return over investment or the “ROI” in a much better manner, and helps the stakeholders to decide and prioritize the development activity as well as production processes. Scrum is all about incorporating dynamic changes during project development, and promotes the primary goal of delivering maximum business value within a limited or minimum time scale. It is possible to achieve dynamic development processes by properly implementing scrum and controlling the sprint activity in an efficient manner.

Importance of sprint activity, or iterations, in catering to constantly changing project environments
Projects can be complex. They can also be subjected to ongoing market trends and changing user- associated requirements. While developing very big or complex projects, it can be difficult to assign fixed goals or objectives. Development takes time. More than often, the functionalists or facilities linked up with a particular project may become obsolete or redundant over time. This can create problems with the development activity if the organization is following traditional waterfall or linear development methodologies. It becomes very difficult to incorporate the changes in such methods since the entire project has to be initiated right from the beginning – from scratch. This result is a significant loss of working hours and productivity. This is where scrum comes in. Scrum framework supports changes occurring in the project environment in a dynamic manner. It is also possible to consistently evaluate the development related requirements, and make amendments in the project development plan in an instant, without any significant loss of time or resources. Moreover, it is much easier to identify redundancy levels and put a curb on nonproductive developmental activities – simply because the sprint process incorporates dynamic updates within the product backlog as and when required. The product owner can update, remove, and add user stories or requirements in the product backlog, and the same can be taken up for development purposes in the sprint backlog. This is the main essence of scrum, and the primary reason why scrum is so popular as a development methodology.

How can you dynamically incorporate changes into your ongoing project or production plan?
Scrum planning and implementation starts with the creation of the product backlog – the list of requirements needed to develop the project in totality. In a typical project, the end product is segregated into its basic constituent parts called user stories. The product owner represents the interests of the stakeholders, and is therefore responsible for creating the product backlog.

During the implementation process, the product owner determines the priority of the importance of user stories and transfers them to the sprint backlog for development purpose. Team members take up user stories on the basis of their levels of expertise and start developing them during the sprint. After the end of each sprint, user stories are checked for acceptance levels. If they are found to be acceptable i.e. “shippable” they are accepted as “Done”. In case the development remains unfinished, the incomplete user stories still go back to the product backlog, where the product owner reevaluates their importance and priority, and eventually decides whether to send the incomplete stories back to the sprint backlog for further development, or to mark them as redundant and do away with them. This is how scrum helps to check undue wastage of development time and resources, since the requirement is evaluated every time the sprint cycle ends. If the particular development is found to be non-productive, they are simply taken away from the sprint backlog.

On the other hand, if the owners or the stakeholders feel a new functionality or facility might increase the market value of the ongoing project, the new set of requirements can be easily added as user stories in the product backlog, and the product owner can simply include them in the sprint backlog for development purposes.  This is how scrum can dynamically incorporate changes in an ongoing project.


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


Thursday 6 February 2014

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"