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" 

3 Serious Pitfalls Which Every Scrum Master Should Avoid – Implement Scrum Successfully

The scrum master holds a very high position and an important one too, while executing projects using scrum methodology. The main role of the scrum master is to ensure that the development team effectively employs scrum during the sprint activity. If scrum is properly implemented, each member of the team remains busy with the tasks allotted, or taken up, by him or her. It is not required for the member to seek guidance from the scrum master as to what should be done next, or what task need to be carried out. The main objective of the sprint planning meetingheld before the commencement of the sprint is to ensure that proper and enough tasks are taken up by each team member. However, at times due to various reasons, which ought to be avoided at all costs, the scrum master knowingly or unknowingly transgresses his or her responsibilities, and extends the primary role of the scrum master. This can lead to undesirable results and ineffectual implementation of scrum methodology. It can also lead to increased development costs and bloated overheads – something every business owner tries to avoid at all costs. So how does a scrum master know that he or she is making a mistake? How does the person find out whether he or she is transgressing the responsibilities associated with being a scrum master?     

The three main mistakes of a scrum master

It is not an easy task to become a scrum master. If the person is new at the job, or lacks enough knowledge or experience as a scrum master, it can be very easy to fall back upon doing what project managers know best – behave and function as traditional managers. It can be very easy to fall into this trap, and many scrum masters often fail to avoid this pitfall during the early stages of their career. A scrum master is not supposed to behave as a typical project manager. Scrum methodology does not support or subscribe to it. Certain indications can help you identify and avoid the pitfalls:    

 

1.    Start assigning tasks to team members

During the sprint process, if scrum is implemented properly, each team member has enough tasks on hand to last the entire sprint duration. The very purpose of holding a sprint planning meeting before starting with the sprint is to ensure that proper and enough tasks are taken up by each team member, and each task is allotted a predetermined time during which it is to be completed. So when scrum methodology is enforced in a proper manner, team members generally do not run out of tasks, and are not required to ask for new tasks when the sprint is currently underway.

Pitfall

As a scrum master, if any team member runs out of tasks and approaches you for new tasks before the current sprint is over, you might be inclined to allocate new tasks to the person. This is a pitfall, and should be avoided. It means that the sprint planning meeting was not done in the correct manner.Read more on http://blog.quickscrum.com/post/2014/01/29/3-Serious-Pitfalls-Which-Every-Scrum-Master-Should-Avoid-%E2%80%93-Implement-Scrum-Successfully.aspx

                "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

Is It Possible To Use Scrum For Developing Non IT Based Projects? If So, How?

Scrum for non-IT based projects?

Whenever people talk about scrum, they mean a methodology which is capable of adapting to changing development environments, and time bound delivery. Since a very long time, for as long as a decade, scrum has been synonymous with IT development. People tend to think about IT projects when ever scrum is mentioned. The old school of thought often failed to think about scrum as capable of dealing with projects other than IT development. The promoters of scrum rarely though about using scrum for production based or manufacturing related processes. This attitude created many hurdles in making scrum methodology popular in the initial years. Even now, scrum is more popularly associated with IT related development projects. Over the years, the question which has always kept on popping up is “Can scrum be used for projects other than IT?” It is a good question to answer, because a lot of confusion has been prevailing regarding scrum, and how it can be implemented for projects other than those which are information technology based.

Scrum framework versus waterfall methodology 

Whatever the product or manufacturing process may be, business owners and companies are always pressed to bring in products which are efficient, easy to produce, and which consume very little manufacturing time. One of the biggest concerns for the development team is catering to the changing market conditions and trends. More than often, the primary objectives and functionalists associated with a particular product to be manufactured may lose its importance and market value. This may happen if a newer version or product is launched which offers a better pricing and added feature, which is not present in the product being developed. Traditional waterfall methods fail miserably when the product definition is changed overnight. This is where scrum can score, since the framework is specially developed to incorporate changing development related conditions. Theoretically speaking, regardless of the type of development, scrum can be successfully implemented to produce any type of product or goods. It can be successfully implanted in various fields dealing with market segments such as government and education, including a wide range of industries encompassing automotive design, venture capitalism, and retail.   

Co-relating scrum with traditional development processes – Is scrum feasible?

Implementation of scrum requires a lot of imagination. Even though scrum methodology rules are simple and straightforward, they have to be implemented properly to be effective. No two development projects are alike. What works well in a particular project may not prove to be quite effective in another. This is where the imagination comes in. Scrum projects have to be molded in accordance to the project’s particular requirements. While project managers have been making minor changes to mould IT based projects to suit scrum, it should not prove to be very difficult to implement scrum in non-IT based projects. The basic rules of scrum remain the same, irrespective of what product is to be developed or manufactured. For non-IT projects, the product assembly list might be substituted with a product backlog while the actual assembly process could be carried out in the form of sprints. Instead of a supervisor or a production manger supervising the assembly process, the scrum master might overlook the implementation of scrum. The implementation can be carried out using a single sprint, or if required, multiple teams could carry out individual sprints to suit the manufacturing process. Implementing scrum for non-IT projects may not prove to be so difficult if you have the inclination and the foresight to correlate traditional manufacturing process with scrum methodology.     

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

Source:- http://storify.com/quickscrum/is-it-possible-to-use-scrum-for-developing-non-it

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”

Understanding And Identifying Risks During Scrum Project Implementation – Avoid Potential Pitfalls

A risk can be understood as a particular event, which is uncertain in its outcome, and which can affect the results of objectives planned to be achieved from a particular project. Risks can lead to the success or failure of a project. Risks, which can lead to positive results, are interpreted as “opportunities”, while those, which can adversely affect, or create a negative outcome, should be understood as “threats”. It is important to manage the risks associated with a project on a proactive basis. Moreover, active efforts should be made to properly analyze a project for the risks involved, or associated with it. The analysis should be ideally carried out before the project is initiated. Thereafter, the analysis should be carried out on a routine basis, and frequently, until the project is successfully completed. A proper and effective procedure should be followed to identify and analyze the risks. It is imperative to follow a standardized routine which can correctly identify, evaluate, and provide a valid and effectual solution of a possible threat which can adversely affect the project’s outcome. 

How risks should be addressed

First of all, it is important to identify the risks. Once they are correctly identified, they should be classified depending upon how severe they are, and up to what extent they can affect the project’s outcomes. Risks, which are likely to create a greater impact, should be addressed first, followed by those which can create a lesser impact. To determine how risks can affect the results, it is imperative to find the root cause, identify the area of uncertainty, and what kind of potential damage they are likely to cause.

Identifying risks during scrum implementation     

Scrum projects too are associated with certain developmental risks. Even though the risks may not be fatal or critical in nature, they may nevertheless result into excessive loss of money in terms of redundant development activities or non-performing projects. As per the “The Scrum Body of Knowledge”, ad definitive guide which deals with the explanation of scrum and how it ought to be ideally implemented, each team member should be able to identify potential risks as and when they are likely to surface during the project implementation. Moreover, risk identification should be an inherent part during the implementation process, and should be carried out on a regular basis. Some suggested techniques might help you identify the risks in scrum:     

1.    Lesions learnt from sprint retrospectives

Sprint retrospective are specially conducted to identify any pitfalls which might occur during the sprint activity. Generally, problems are detected during the retrospective discussions since product owners and team members discuss various topics in depth and put in efforts to find out how effectively the sprint has progressed, and what kinds of problems are likely to arise during the development activity. They are a great way to identify any potential problems which may affect the project over a period of time, or which are likely to surface in the near future during an ongoing sprint.

2.    Risk checklists

The risk checklists include certain key points which are identified as root causes capable of inducing risks during the project implementation. Generally, the list includes those factors which are encountered while the sprint is underway, or when the project is being implemented. Risk checklists contain problematic causes which are often anticipated by the team members capable of causing potential problems.  

3.    Risk prompt lists

These lists are generally created out of brainstorming sessions. They may not necessary hamper the project, or cause impediments for sure, but they are potential pitfalls which team members should be wary of during the project implementation.

4.    Brainstorming sessions

They included in-depth and detailed discussions regarding problems likely to occur during the planned sprint or project implementation. Usually more experienced team members take part in these discussions, and they contribute their suggestions based upon their experience and levels of expertise.   

5.     Risk breakdown structure

This is an important tool, or technique used to identify potential key risk areas of development which can lead to problematic situations as far as development is concerned. Risks are identified and segregated into groups based upon their potential to cause problems. Risks are typically categorized as those belonging to financial, technical, or safety related nature. It allows the team to prepare for any eventualities, which may arise during the project implementation.

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

Source:- http://scrummethodology.webnode.com/news/understanding-and-identifying-risks-during-scrum-project-implementation-avoid-potential-pitfalls/

Scrum Methodology Made Easy – Easily Understand The Basics

Scrum can be understood in simple terms as a loose set of rules or guidelines used to control or govern the process of development of a particular product. The method can be used to develop the product right from its inception up to its finished state of completion. The objective of the scrum methodology is to overcome the shortcomings offered by traditional development methods. Generally, what does scrum help to overcome?

Chaos and problems occurring due to varying or changing development environment

A major problem occurring during the development process is responding to the changes occurring in the product development cycle or requirements put forward by the clients. In case of traditional linear product development methodologies, it is not possible to make any changes in the development cycle once it is decided and put into practice. The entire development stage has to be carried out again after incorporating the new changes in the product design or client oriented requirements. That is not the case with scrum development. Changes can be immediately reflected in the development cycle. Moreover, the changes can be incorporated in live working environments “on the go”.

Responding late to product development impediments

It is very important to respond quickly to, and cater in time to the impediments occurring during the development activity. If large extent of time is required to be spent while responding to the solutions required to remove the problems, the development loses its meaning if it is going to exceed the predetermined product development time. With scrum it is very easy to respond to changes. Any problem occurring, or faced by the development team is dealt within the sprint time.  The daily scrum meetings are basically designed and conducted for this very purpose. This facility is not supported in traditional methodologies.

Uncontrolled development process

In traditional development methodologies such as Waterfall, it is not possible to evaluate the development status on a frequent basis. Generally the project manager is made aware about the development status after a particular stage is completed, and by then it is too late to rectify and errors occurring or unknowingly carried out by the development team. With scrum, the difficulty is overcome due to sprint planning meetings. At the end of each sprint, generally lasting up to two weeks, the status of development is identified, known, ascertained, discussed, analyzed, and rectified for any erroneous process occurring during the sprint. This ensures that the errors are not carried forwarded, but rather checked in time, and catered to.  

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

Source:-http://scrummethodology.zohosites.com/blogs/post/Scrum-Methodology-Made-Easy-%E2%80%93-Easily-Understand-The-Basics/

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/

Effective and Productive Features Of A Scrum Retrospective Meeting – What Every Scrum Person Should Know

Sprint retrospectives are a technique in Scrum, used primarily to reveal or disclose the shortcomings and behavior of the scrum team to itself. When it becomes possible for a self-organizing body or a system to correctly identify the pitfalls and problems faced by it, it is possible to correct them by implementing proper solutions which can eradicate the impediments and remove the problematic issues from its roots. During scrum implementation, sprint retrospectives help to identify any erroneous working or problems faced by the team, and efforts are made to correct the problems in time. For retrospectives to be meaningful and useful, more emphasis should be stressed upon self-reflection – each member of the team should feel personally involved and responsible for the outcomes derived out of the sprint activity. This is one of the main essences of scrum. In addition to collaboration and team effort, scrum framework strongly promotes self-analysis and self-correction. Sprint retrospectives help to incorporate these scrum features during the implementation stage.  

Features of a healthy and beneficial sprint retrospective

The scrum guide has little to say about what an ideal retrospective should consist of. Since scrum is all about adapting to changes and collaboration of activities, it can be very difficult to specify exactly what the retrospective should include. Business processes can vary, and scrum implementation may be carried out in a customized manner to suit the particular organization or business. In short, it may be very difficult to define and standardize a retrospective. Rather, it would prove to be more meaningful and effective if the objectives and results of the retrospective are to be considered, instead of its anatomy or structure. Teams may vary, and can be big or small in size. The location should be ideally fixed, but it too can change as per convenience and feasibility. What does not change are the objective for which the retrospective is to be held, and what results are to be obtained out of it. Ideally, a sprint retrospective should support the following features:

• Each team member should engage in the discussion and actively support it in a pro-active manner.
• Discussions carried out ought to focus upon team activity and teamwork rather than individual team members.
• The definition of “Done” is clearly defined and explained properly to team members. Completed user stories should be accepted as “Over” or “Complete” only on the basis of the definition of “Done”. 
• A list of all actionable commitments should be created.
• The results of prior retrospectives are thought about and analyzed from time to time.
• Only relevant discussion pertaining to scrum implementation should be carried out.

 Who attends the sprint retrospective?

Everybody associated with the scrum project and scrum implementation should attend the retrospective. This includes the product owner and all team members. The scrum master too attends the meeting, but rather than indulging in active discussion, he or she engages in a manner which can facilitate the meeting, and positive results are derived out of it.

 Supporting the correct spirit while holding the retrospective

Regardless about who attends the meeting, or the level of seniority, there should be active participation by all the attendees, and discussions should be carried out in an open manner with a clear view of finding true and genuine solutions, rather than finding faults of individuals. Of course, self-introspection and error finding is a must as far as scrum is concerned, but instead of targeting specific individuals, it is important to discuss about team as a whole, and find solutions collectively. 

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

Source:- http://quickscrum.wordpress.com/2014/02/10/effective-and-productive-features-of-a-scrum-retrospective-meeting-what-every-scrum-person-should-know/

True Meaning of Scrum and Pitfalls To Avoid At All Costs

Scrum, having its roots in Agile, can be effectively employed for almost any type of project. However, scrum is most preferred for software development purposes. The scrum process is ideally suited for rapidly changing project environments. It is most useful, and its potential can be tapped in the best manner, when the user related requirements are changed frequently, or randomly, due to various reasons. The methodology makes it possible to incorporate the changes easily and effectively within its development cycle, and still generate positive outputs.      

The true essence and working of scrum

According to scrum framework, development occurs in short bursts of activity known as “sprints”. Each sprint can generally last from two to four weeks. Each sprint begins with a meeting, known as a “sprint meeting”, and typically concludes with clearly defined and set out development objectives. “Stand up” meetings are very brief, and occur daily before the commencement of the sprint for that particular day. The main objective of the meeting is to apprise everyone about how much development progress has been made since the previous day, and what objectives are to be achieved on the particular working day. The main purpose of scrum is to aid the team members in inspecting and adapting to the changes, and providing transparency with regards the working of the project. Another main advantage offered by scrum framework is to increase the involvement, and the interaction of the client with the team members. The client remains apprised about the most recent development status, which helps him or her to undertake informed decisions about what further development activities are required to complete the project in totality, and what features and functionalists need to be omitted, or which have become redundant during the development cycle.   

Pitfalls while implementing scrum

Scrum is a framework based upon an organized thought process developed specially to cater to changing development requirements, and the main issue with Agile and scrum is that the method is to be implemented, or its rules enforced in a proper manner. Many a times, when organizations are not properly trained in the implementation of the framework, there is a tendency to fall back upon old development methods, consciously or unconsciously, thus making scrum redundant. Traditional development methods such as Waterfall have been in existence since a long time, and people are more familiar with them. Project managers have practiced these methods for a long time, and they are more conversant with them. Scrum can be difficult to implement, and if the manager is not properly trained, he or she may substitute some of the scrum related processes with Waterfall methods. The objective is to provide a specific solution during the development cycle, and when the person fails to implement scrum in a particular development related process, he or she “patches” up scrum implementation process with a Waterfall technique. This should be avoided at all costs. Scrum should be implemented in totality for it to be effective.    

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

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"