What Is A Sprint Planning Meeting And What Does It Consist Of?

Objectives of a sprint planning meeting

In Scrum, 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. Even though it is a single meeting, it in fact covers two unique parts. The first part concentrates upon which of the product backlog items suggested by the product owner is accepted by the team for development purposes and is attended by the entire 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 mandatory attend both the parts of the meeting, while the product owner has to compulsorily attend the first part only. He or she, however, has to remain available for the second part if the team requires any clarifications regarding the user stories.

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 the set of user stories to be developed during the sprint. During the meeting, the product owner 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. The PO has to convey the product vision to the team ensure that the team develops the product features as desired by the end users. The objective of this part of the meeting is to provide enough information, or brief the team members regarding the development activity to be carried out so that each member can carry out his or her part without any confusions or problems.

The product owner explains the acceptance criteria of the user stories and ensures that the team has understood the stories well enough to product a successful product increment. Another 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 second part of the sprint planning meeting

During the second part of the meeting, the team further analyses the user stories and focuses upon decomposing the sprint backlog items which include 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 the basis of their complexity. Once the stories selected from the product backlog are decomposed into individually developable tasks, the team members accept or take up the tasks based upon their levels of expertise and experience. Experienced team members take up more complex tasks, while less experienced ones take up simpler and easily developable ones.

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 to the permanent free version of the Quickscrum project management scrum tool to get an idea about how the tool works and what it has to offer.

Posted in product owner, Scrum, scrum tool, sprint, sprint backlog, sprint backlog items, Sprint Planning Meeting, user stories | Tagged , , , , , , , , | Leave a comment

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 transparency, distribution of work, and incorporating changes even “late during the development stage”. Each individual is assigned a specific role in the scrum framework. 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”. 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 a week to ten days up to a maximum of four weeks.

At the end of the sprint, a meeting is conducted to analyze how much work has been completed and how many user stories are been successfully completed by the team. So, in many ways, the sprint functions as the main essence or the “heart” of the scrum process. Sprint planning plays an integral part in the scrum framework.

scrum tool | scrum | sprint planning

Can a sprint be terminated abnormally before it is completed?

Development teams have to complete the user stories and tasks well within the duration fixed for a sprint. It is very important to complete the sprint if the management desires positive results through scrum implementation. However, under some unusual or rare circumstances, a sprint may be required to be “stopped” or terminated before it has a chance to run its full iterative cycle. It is the product owner who decides whether the sprint can or should be terminated.

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

Check our extensive Agile Scrum knowledge base covering a host of topics which may prove useful to you in understand Scrum framework.

Posted in Agile, Agile Scrum, Agile Scrum model, product owner, Scrum, Scrum Agile, Scrum Agile process, Scrum Framework, Scrum Methodology, Scrum process, Scrum process model, scrum tool, sprint, sprint backlog, sprint backlog items, Sprint Planning Meeting, user stories | Tagged , , , , , , , | Leave a comment

What Are The Core Principles And Features Of Agile?

Main Features Of Agile

Many IT products development companies and software businesses experiment with Agile frameworks and processes such as Scrum and XP to improve upon their development process and avail higher investment returns. In many ways, Agile has become synonymous with software development and is rapidly emerging as the number one choice in terms of project development frameworks. Many project managers prefer Agile in lieu of other project development methodologies. The reasons are many. Certain features of Agile remain common to all Agile offshoots such as Scrum, XP, Kanban, etc.

It is worth knowing what the core tenets of Agile are:

scrum tool |Agile | scrum

12 core principles of Agile

An overview of Agile development method

Twelve core principles define the Agile process:

  1. The topmost priority is to satisfy the customer requirements through the delivery of early and quick product releases – deliver valuable software on a consistent basis.
  2. Working releases of product features should be delivered frequently, ranging from a week to ten days, up to a maximum of one month.
  3. Progress should be measured of the basis of working software delivered to the client. Software is more important than its documentation.
  4. Changes should be welcomed, and incorporated into the product development cycle – even late during the development phase. The team should learn from the “inspect” and “adapt” principles and conѳtantly try to improve its working.
  5. The client and end users should work together through collaboration and collaborative processes … Read more>>>
Posted in Agile, Agile principles, Agile Scrum, Agile Scrum model, Core Agile principles, Scrum, Scrum Agile, Scrum Agile process, Scrum Framework, Scrum Methodology, Scrum process, Scrum process model, scrum tool, XP | Tagged , , , , , , , , , | Leave a comment

Is Scrum a methodology?

Scrum – A methodology?

Scrum is an Agile based framework which can be easily applied in almost any type of project. Scrum, however, is most commonly used for software development, and is a very popular environment for developing wide-ranging software based products. The framework is ideally suited to project conditions where the product may undergo rapid changes, or may have highly emergent requirements.

Agile Scrum is fundamentally based upon three basic principles.

  • Product owners plan and decide what needs to be developed, or built, in the next couple of months or less. They plan the project, work out the project dynamics, and design a project process flow that is most suitable for their unique project related requirements.
  • The development team builds the product in stages through the sprint iteration cycles. At the end of each cycle, the PO and stakeholders verify that the development is OK. The team ensures that important product features are developed first, followed by less important ones.
  • Scrum masters make sure that the Scrum process is followed, and implemented properly. If the team faces any issues, technical or otherwise, the scrum master resolves the issues.
Scrum Process

Scrum Process

An overview about the Scrum Agile process

Project work in Scrum begins with the creation of a master list known as a product backlog. The product owner creates a list which contains all the features required to develop the product in totality. Once such a list is prepared, the actual Scrum process can begin. Scrum functions through repetitive iterations known as “sprints”. Each sprint traditionally extended from two weeks up to a month. However, Scrum has now evolved to last for seven to ten days owing to rapid project development requirements and dynamically changing market trends. Scrum development methods suggest that each sprint should begin with a short meeting, known as a daily scrum meeting, in which the entire team plans what it proposes to “do” on the particular “working” day.

The entire product is developed in short bursts of development activity known as sprints. The product is broken down into its constituent features, and each feature is developed as a user story in a sprint. Moreover, each feature, in the form of a user story, should be “successfully” developed such that it does not have any flaws or bugs. Each sprint, in short, should only produce “shippable” products.

Once the feature is developed, it has to be … Read more >>>

Posted in Agile, Agile Scrum, Agile Scrum model, Scrum, Scrum Agile, Scrum Agile process, Scrum Framework, Scrum Methodology, Scrum process, Scrum process model, scrum tool | Tagged , , , , , , , , , | Leave a comment

What Is A Sprint Planning Meeting Agenda?

The sprint planning meeting agenda

In a Scrum project, the Sprint planning meeting agenda is one of the most important activities undertaken by the team. The product owner plays an important part in the agenda. In Scrum, out of the many important duties carried out by a PO, a very important one is to create the product backlog based upon the vision of the stakeholders, and subsequently maintain or “groom” it with the help of team members (preferably). However, once the backlog is created and all required product backlog items are properly defined in it, it becomes necessary to “prepare” for the next step in the Agile product development cycle – plan and develop effective sprints so shippable user stories are delivered at the end of sprint cycles. Offering consistent development over successive sprint iterations is an inherent feature of Agile Scrum. In a sprint planning agenda, the objective of a sprint meeting is to prepare productive sprints so the team can develop meaningful stories.

So, what does a sprint planning meeting actually consist of? In practice, the meeting is conducted in two parts – the first part is dominated by the product owner while in the second part the development team actually prepares tasks from user stories taken up for development in the sprint backlog.

scrum tool | sprint planning meeting

Sprint Planning Meeting Agenda

First part of sprint planning

The product owner is the most “conversant” person as far as user stories are concerned since he or she actually “creates” the product backlog. The stories need to be explained to the team members. During the first part of the Scrum sprint planning meeting, the PO selects some of the most important product backlog items from the top of the backlog, and creates a “sprint backlog” by transferring the selected stories into it. So, the sprint backlog is a subset of the main backlog, and contains a “chunk” of stories which carry high business values. The PO explains how the development of a particular story should be carried out by the development team. The acceptance criteria is explained and the team is briefed regarding what it should do to ensure their “development” is shippable i.e. the stories are bug free and satisfy the benchmarks or acceptance criteria linked with each story. The PO also answers any doubts or queries put up by the team.

The first part is attended by the entire team – the product owner, scrum master, and the development team members. It is not necessary for the stakeholders and project owners to attend the meeting, but if they desire to do so, they can attend the meeting as “passive” invitees, and not disturb the proceedings with their suggestions or even try to get “involved” in the meeting.

Second part of sprint planning

User stories form the base of all development activity in Scrum. The entire product is developed by creating shippable stories, which are later integrated to “form” the complete product. During the second part of the Scrum planning meeting, the team starts discussing how it will … Read more>>>

Posted in Agile, Agile Scrum, Agile Scrum model, Scrum, Scrum Agile, Scrum Agile process, Scrum Framework, Scrum Methodology, Scrum process, scrum tool, sprint, sprint backlog, sprint backlog items, Sprint Planning Meeting | Tagged , , , , , , , , , , | Leave a comment

How Should Acceptance Criteria Be Defined In Scrum?

Acceptance Criteria In Scrum

In Agile Scrum, the product owner reviews the user stories during the sprint review event, and checks whether their acceptance criteria is met before clearing them for a client demo. He or she will never clear a story if its acceptance criteria are not met. Scrum framework advocates that bug free and shippable user stories be developed through the product incremental cycles. Each product feature carries a certain business value. At the time of development, the feature should be developed so that its usefulness is sustained in the market i.e. the feature should function as per the product vision seen by the stakeholders. For this to happen, it is important for the development process to satisfy the technical terms and conditions as specified in the backlog items. The acceptance criteria specify conditions which need to be fulfilled by the team, so the feature can retain its business value in the market. Acceptance criteria are important for the scrum process. The product cannot be released unless the acceptance criteria of the backlog items are met during development.

How should acceptance criteria be defined?

In all Agile frameworks including Scrum, the acceptance criteria should be expressed clearly in the product backlog items. It should be stated using a simple language so it becomes easy for the team members to understand and follow it. Moreover, the story should be described in a manner such that it can be understood without facing any ambiguities regarding its possible outcomes – what is acceptable and what is not – the technical team should be able to understand what is to be developed and delivered, in what manner, and what conditions should be satisfied so it can be considered as shippable.

What is the purpose of defining acceptance criteria?

The acceptance criteria helps the team to understand what a user story should ideally deliver in terms of a product increment, and what it should do to maintain the usefulness of the feature. End users have a final say regarding what is exactly required in terms of feature functionality. Based upon their feedback, the product owner ensures that the acceptance criteria reflects end user conditions, and conveys those requirements in the acceptance criteria.

The acceptance criteria:

  • Defines the limits or boundaries of a user story or feature in the product backlog.
  • Helps the product owner to answer what is needed in the feature so the team can deliver the expected business value.
  • Helps the team to understand and share ideas regarding how the team should develop the feature.
  • Aids the team in testing the feature development so it can be accepted as “Done” by the PO and stakeholders.
  • Helps the team in understanding how much further development is required to finish the story.

What should the acceptance criteria actually include?

The acceptance criteria should be defined while maintaining its “scope”. To be effectual, the criteria should be written following certain guidelines.

  • It should try to explain the intent behind developing the product feature. It should not try to provide a non-debatable solution. Team members can argue regarding its acceptance while negotiating user stories with the PO during the sprint planning meeting event.
  • It should be independent of its implementation. The acceptance criteria should not suggest or limit how the story should be developed. The team decides how the story or product feature should be developed since it “owns” the sprint backlog.
  • It should be explained at a macro level and provide an overall picture about what is actually needed.

When to write the acceptance criteria?

The product owner is responsible for creating the product backlog at the time of project planning. All user stories depicting the product features as envisioned by the client are stated in the product backlog in the form of product backlog items. The product owner should write stories and acceptance criteria. However, as per the role of the product owner as suggested by the Scrum guide update, the PO is to be held accountable for creating and maintaining the product backlog. It does not necessarily mean that the PO should personally create backlog items and state the acceptance criteria in the stories. The development team can aid the PO in writing the stories and stating the acceptance criteria in it. The product owner, however, has the final say what the acceptance criteria should ideally include.

Use the permanent free version of the QuickScrum scrum tool to implement Scrum into your ongoing projects. Discover how the dynamic tool features can help to increase your productivity and reduce operational costs.

Posted in Agile, Agile Scrum, Agile Scrum model, product owner, Scrum, Scrum Agile, Scrum Agile process, Scrum Framework, Scrum Methodology, Scrum process, Scrum process model, scrum tool | Tagged , , , , , , , , , , , , , | Leave a comment

How To Understand The Agile Manifesto

Importance of the Agile manifesto

The popularity of Agile frameworks, especially XP and Scrum, is increasing by the day, and more and more organizations are deciding in favor of using these frameworks to execute their projects. Agile proposes many advantages – frequent and reliable product increments, delivering product features having high business values, and above all – delivery of shippable product features even while the development process is underway. However, a major issue with Agile, and all Agile based frameworks is that the framework has to be properly understood and later implemented in the project. Moreover, the implementation should be carried out keeping Agile principles in mind. More than often, businesses fail to benefit from Agile simply because the management has not understood the basic principles behind the framework, or has failed to implement those principles in a proper manner.

The Agile manifesto

Since it was developed in 2001, thousands of individuals including project managers, software professionals, and C level executives have endorsed the Agile manifesto. Hundreds of books and references have been written to discuss what the guide has to say, and how it should be interpreted. The manifesto has drastically changed the way in which organizations and individuals develop software projects. The manifesto packs a lot of punch for its 68 words which have been written by 17 software professionals over a two days meet at a ski resort.

The principles of Agile are stated in the official guide written by Ken Schwaber and Jeff Sutherland. The guide functions as a bible for all Agile groups and Agile professionals. People refer to the guide when in doubt, or when they wish to clarify a particular point during Agile framework implementation. For individuals interested in Agile, it is very important to understand the guide and interpret what it has to say.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

To start with, the manifesto states “We” i.e. it emphasis that Agile is not a solo endeavor. It involves group activity and people have to collaborate while working, at every level, and at every instant. Development teams, project teams, and organization have to work jointly as a composite unit, and rely upon each other for completing work.

are uncovering
Here, the guide suggests that Agile does not offer one-size-fits-all type of solutions. Agile cannot be standardized and implemented in a project. People involved with Agile processes have to put in efforts, and strive to seek answers through discussions and collaborations. Answers have to be discovered through experimentation, and the “adapt” and “inspect” principles which are so dear to Agile. It is important to explore new ideas and eliminate those activities which are counterproductive or not effective.

better ways of developing software
Nobody is perfect. Also, no framework or methodology can be perfect. Instead of concentrating upon perfection, the Agile team ought to concentrate more upon improving the current work process and finding better ways of doing things. Small improvements, gradual but consistent, should be incorporated in the process to make it more efficient and result oriented.

by doing it
The bottom line – build the software and deliver it. The best way of finding out whether something works or not is to build it and try it out. Failures should be seen as learning lessons, and the team should learn from them. Better methods of working originate from experimentation and the learning process. Rather than spending undue time thinking over whether something will work properly or not, it is better to do it, and learn from the results availed through the implementation.

and helping others do it.
Agile is all about sharing. People have to share their ideas and experiences with each other. It is not required to make a mistake and learn from it – one can learn from the mistakes made by others. Knowledge should be shared and opinions sought for. Senior team members should try to foster a healthy working environment, and act as mentors for those new to Agile.

Through this work we have come to value:
The manifesto was envisioned and drafted by 17 seasoned professionals closely involved with various project development methodologies and processes. They represent the core market requirements. Through their experiences and knowledge, the manifesto was designed to target what clients really desire in a project, and how the team should function to satisfy those requirements in the best possible manner by delivering time bound projects having high business values. Agile principles should be taken seriously and valued by all concerned.

Individuals and interactions over processes and tools
Bob Martin has correctly described Agile as “a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work.” The Agile team should primarily focus upon working together while developing the project, and ensure that a productive and healthy working environment prevails at the place of work. If anything – tools, processes, or activity – disrupts the way in which individuals closely work together, serious thoughts and considerations should be given to the issue, and the impediment should be removed without wasting further time.

Working software over comprehensive documentation
All Agile frameworks including Scrum focus upon the delivery of working software releases through product increment cycles. The main goal is to deliver product features on a frequent and consistent basis to the client. Resources and time should not be wasted over lengthy documentation. Instead, the team should focus upon delivering the business value to the client. If you have to decide between spending time and efforts over completing the documentation formalities, and in delivering the software, you should opt for the latter. The reason why Agile discourages comprehensive documentation is that people would than require more and more time to read the stuff, analyze what they have understood, and spend even more time wondering what to do next. As a result, they would actually find less time to work upon the project and complete it.

Customer collaboration over contract negotiation
The client is the most important entity in Agile. The process invites stakeholders’ participation and encourages them to become involved with the development process. Agile proposes to deliver high quality working software that meets the actual, and exact, requirements as specified by the client. The team should concentrate more upon collaborating with the customer and delivering the business value, rather than sticking to contract conditions and legal formalities. It means that the team should try to focus upon delivering what the customer really needs rather than honoring and following what the contract says.

Responding to change over following a plan
Agile is recommended and ideally suited for developing projects prone to changing market conditions. It thrives in situations where the product design is liable to change with time. Changes occurring in the features and functionality associated with the product can be easily incorporated in the process flow, and developed by the team. The unique aspect about Agile is that the changes can be incorporated even when the team is developing the product, and changes can be carried out even late in the product development cycle. The team should be positive towards changes and welcome it. Changes offer an opportunity to deliver something that is even better than what was originally planned.

That is, while there is value in the items on the right, we value the items on the left more.
Agile is a framework. The principles have to be implemented in a workflow or development process, to mold it so it can be more effective. Agile does not suggest you do away with traditional tools and development processes. It merely offers a way of making your existing development process more effective and productive through its principles. The ultimate objective is to deliver a valuable product to the client and foster good relations with him or her.

Read more about the Agile manifesto at QuickScrum – Visit now!

Posted in Agile, Agile guide, Agile manifesto, Agile Scrum, Scrum, Scrum Agile | Tagged , , , , , , , , | Leave a comment

Why Agile Can Be A Popular Software Development Framework

Agile A Popular Software Development Framework

Software products penetrate almost every aspect of human existence today. They manifest themselves in a multitude of manner, and remain omnipresent in a host of devices ranging from washing machines and smartphones to automobiles and computers. Owing to a consistent usage of different types of digital devices by people across the world, software applications and utilities have to evolve as and when consumer requirements change and “strive” to fulfill the new set of requirements demanded by end users. It is, therefore, essential to develop newer versions of existing software products more frequently, in the shortest time possible, and in a manner such that end users do not face any problems while using the products in the upcoming months. Stiff market competitions and an ever-increasing consumer “appetite” for feature-rich products have created a special need to implement a reliable and sustainable product development methodology, or a framework, which can aid in developing sophisticated software products in a relatively short time. Moreover, the methodology should also help in reducing the developmental overheads so investment returns can be increased. As on today, a reliable project development methodology is very much required to fulfill the business goals on a consistent basis, and earn large profits from the products manufactured by IT companies.

Over the decades, IT stalwarts have introduced many software development frameworks and project management methodologies. While many of these methodologies have proved to be useless and non-productive, a large number of them have been, in fact, successful in delivering the desired results – with varying levels of acceptance. With the passage of time, two software development frameworks have managed to dominate the field of software development. The frameworks are:

Agile Scrum Tool

1. Waterfall

It is a traditional software development framework typically featuring “staged” development processes which have to be “carried out” one after the other. A unique aspect about this framework is that product development starts from the “topmost” stage and “flows” towards the “bottommost” stage. Once started, the product development cycle cannot reverse itself – it is unidirectional in nature. The framework is widely used, and is very popular amongst software development companies, primarily because the framework has “been around” for a long time and used by a large number of software developers and IT firms. It is easy to understand and use. Therefore, it is also used for teaching the software development process to engineering students. Even though it is a much sought after development framework, a large number of individuals and companies traditionally using Waterfall methods for developing their software products are now finding it increasingly difficult to meet the changing global software trends, and developing state-of-the-art applications and utilities, which are so much in vogue today.

2. Agile

A comparatively new “entrant” Agile has managed to find a special niche for itself in the IT development field over the years. The Agile framework was originally envisioned, and developed, to overcome the defects of traditional software project management methodologies and frameworks, which had failed to evolve “in the desired direction”, could not adapt themselves to the changing market trends, and offer reduced turnaround times. There are many reasons why “lightweight” Agile frameworks have become popular development platforms:

  • They support product development through “short bursts” of programming/development activity, generally lasting from two weeks up to one month. It is much easier to develop, test, and document smaller “pieces” of code, features, and functionality rather than entire projects. Individually developed features are later integrated to form the “complete” product. The frameworks primarily focus upon rapid delivery of “shippable” products and business value.
  • The client is actively involved with the team and the development process. Each feature is checked and “cleared” by the stakeholders before it is accepted as “Done”. This leads to increased customer satisfaction and enhanced user experience.
  • Potential pitfalls are identified well in advance, at a micro level, so it is much easier to control regression and reduce technical debt. Agile software projects generally help to earn good profit margins.
  • Agile frameworks support error detection and error correction processes. Technical errors are discovered early during the product development process, and dealt with effectively.
  • The frameworks provides an opportunity to carry out “retrospective” thinking, reflect in terms of where the project is heading, and what “more” could be done to improve the product development process.

Agile and the scope of software development

Individuals associated with the software industry generally prefer using the term “software development” to describe their particular line of work. The words are indiscriminately used to describe a host of development related activities, including testing, documentation, debugging, deployment, and maintenance of software applications. It is normal to explain one’s profession as “software development” while the individual may be working as a VBScript or Java web developer, an application programmer, an iOS or Android mobile apps creator, or even developing specialized scripts for WordPress themes.

One of the commonest doubt prevailing amongst most individuals new to the Agile process is whether Agile is “applicable” to their particular field of work. And if so, how? In what manner? How can they possibly benefit through Agile? The questions are many. First of all, it is important to know where Agile is applicable, and whether it “covers” your particular field of work. Please read to know more about Agile “applicability”. The list provides a rough idea regarding the scope of Agile software development.

1. Clients and stakeholders engagement

Product Backlog

Agile emphasizes upon client engagement. The stakeholders “own” the project and sponsor it. Their objective is to develop successful software projects, and generate higher sources of revenue out of them. In practice, the client remains conversant with the current market trends, and possesses a fair idea as to “what” is likely to score in the market in terms of a feature rich application or utility that can satisfy the end user requirements. When the client is closely associated with the day-to-day development activity, he or she can decide whether the productivity offered by the development team can satisfy user related requirements, and how much of business value the product features possess. Client participation leads to meaningful and successful project development and completion.

Waterfall does not encourage or support client participation. The project is developed, and subsequently presented to the client after it is totally completed. Since the client does not participate in the development process, Waterfall projects may fail to offer the exact features so desired, and, in addition, do not “guarantee” any business value for the project. There is a certain risk involved regarding the product’s saleability. 

2. Transparency and collaboration

free Scrum tool

The Agile framework makes it possible to increase the transparency levels while working, and facilitates the actual product development process by increasing the collaboration amongst team members. Information pertaining to the entire project is shared equally with all team members, and each decision undertaken by the senior team members – the product owner and the scrum master – is freely discussed. The seniors “act” as mentors, and many a times employ a servant-leader role to increase team participation. The team members have the authority to accept or reject the tasks taken up for development. Moreover, the developers have the right to allocate or distribute development tasks amongst themselves. Seniors do not allocate work to the development team members. All these factors create a healthy working environment. A conductive Agile work-related atmosphere leads to meaningful development and timely completion of product features.

The Waterfall framework primarily concentrates upon delegation of authority and direct allocation of work. Unlike Agile, the development process is pre-decided, and in many cases, even decided as to which resource should be used for developing a particular product feature. Waterfall is rigid as far as sharing of information is concerned. The project related documentation is created at the project’s onset, and apart from technical information, nothing else is generally shared with the team. The seniors have the final “say” and junior team members cannot argue with any of the decisions undertaken by the seniors.

3. Quick and predictable delivery

scrum tool

Apart from the actual development activity, Agile supports several events and activities which constitute the actual Agile process. Each activity is time-boxed and has to be completed within a stipulated time. It is one of the most important framework features. Quick and sustained delivery of shippable products through periodic product incremental cycles known as “sprints” comprise the main heart of all Agile frameworks. The deadlines are stringently adhered to and rarely compromised upon.

One of the biggest drawbacks of Waterfall is that projects, in many instances, extend well beyond their stipulated deadlines, and rarely get completed in time. It is an inherent drawback which actually inspired the “birth” of Agile and Lean frameworks. Traditional development methods are rigid, and it is very difficult to control the rate at which productivity is offered by the team. That is not the case with Agile. Each Agile sprint is dynamic, and “monitored” on a daily basis through the daily scrum meetings so it can be “made” effective. Agile concentrates upon quick and timely delivery of product features and functionality through daily development activity known as “daily sprints”.

4. Predictable costs and work schedule

online scrum tool

It becomes possible to predict the amount of work done, or productivity offered, by time boxing the daily sprint iterations. The development carried out can be frequently and easily monitored since each “daily sprint” has to result into something “significant” with regards the development of product features, and the same has to be exhibited to the product owner and the stakeholders in special Agile events known as the “sprint review” and “sprint retrospective” meetings. The “velocity”, or the rate at which actual development is carried out, is used for estimation purposes i.e. the total number of tasks developed by the team during a particular sprint provides an idea about how much work was carried within a specified time. The estimation makes it possible to predict how much time and financial resources will be required to complete the project. A reliable project release date can be subsequently stated.

It is very difficult to estimate how much time a Waterfall project will need to complete. Deadlines are generally “set up” based upon predictions and project related experience, rather than on actual project dynamics and production pattern. It is one of the primary reasons why Waterfall fails to deliver time bound projects.

5. Support for “change”

Product Owner

Agile is based upon “inspect” and “adapt” principles. The Agile framework dynamically supports changes, and is capable of adapting itself to changing market related conditions and client demands – even late during the development process. New features can be introduced to enhance the product’s business value, and redundant functionality can be safely “removed” from the production plan without affecting the productivity levels.

Waterfall does not support, nor advocate, any types of changes once the documentation process is carried out, and the project commences. The framework is rigid and there is no scope of changing the functionality stated in the documentation process – even if the client so demands.

6. Focusing upon the business value

project management tool

In Agile, development is carried out by splitting the actual product into smaller developable parts known as “user stories” or product items. Right from the project conception stage, each user story is segregated and arranged depending upon its importance and business value. User stories having a greater business value or importance in the project are developed first, followed by less important ones. Thus during the Agile process, only important product features are developed at all times, thereby increasing the business value linked with the project currently underway.

Waterfall does not have features that can account for or take into consideration the current business value linked with the project. The concept does not exist. Projects are developed in a traditional manner, and no efforts are made to determine what they are currently worth in the market.

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

Posted in Agile, Agile Scrum, Agile Scrum model, Scrum, Scrum Framework, Scrum Methodology, Scrum process, Scrum process model, scrum tool, Waterfall | Tagged , , , , , , , , , , , , , , , , , | Leave a comment

What is Scrum process?

The Scrum process

Scrum is a better way for development teams to work together and “manufacture” a product. In the Scrum Agile process, development is carried out in “small pieces”, with each piece contributing towards the product’s overall “growth”. Building a product in segment or pieces makes project management much easier. It is easier to track, monitor, and “redesign” small pieces of the product rather than the actual product. Moreover, when small segments of the product are developed on a periodic basis in a sustained manner, it becomes feasible to adhere to the project completion deadlines.

How does the Scrum process model work?

Scrum is a framework, and not a methodology. Most people tend to confuse between a framework and a methodology. While methodologies are exact processes and have to be followed in a “prescribed” manner, frameworks are more flexible and have to be implemented in a project before their benefits can be availed. Quite often, a project has to be “molded” as per the framework. In Scrum, a project has to be “designed” in such a manner that it supports the principles and ideals supported by it. The actual product has to be broken down into smaller, easily developable “user stories”, and each story has to be designed and developed on an individual basis. Moreover, each story can be stringently tested for any bugs and should be “released” only when it is regression free. Scrum supports product incremental cycles i.e. the entire product is developed in parts through consistent and sustained development of smaller, individual product features through repeated process cycles known as “sprints”.

Important features of the Scrum Agile process

Developing a complex project or building a complicated product may prove to be a difficult task. Scrum offers a framework specially designed to make “difficult” work easy and “more” manageable. The main reason why Scrum succeeds where other frameworks and methodologies fail is that it concentrates more upon “human” involvement and decision-making. Scrum teams need to collaborate to get things done. Moreover, team members have to share their ideas and experience to expedite the development process. In many ways, Scrum is a simple framework and easy to implement if one “learns” it in a proper manner. It is important to know what is Scrum process before implementing it.

Three main roles govern how the Scrum process works.

  1. In the Agile Scrum model, the product owner plans what needs to be done and in what manner. He or she thinks about an effective project design and works out possible ways and means to implement it in a manner such that the product is developed in the least possible time, and the project maintains its “business value” or market worth at all times.
  2. The development team has to support the stakeholders and the PO’s vision regarding project development. It has to collaborate, plan, and actively facilitate the product increment process so that “shippable” user stories are developed at regular intervals.
  3. The scrum master has to ensure that the entire Scrum process is properly carried out and the team does not face any technical difficulties or hurdles.

The Agile Scrum model overview

  • While discussing the Scrum process model, the product owner creates a master list containing all product features and priorities it depending upon the importance of the product feature, and how much the particular feature is “worth” in terms of its saleability. The list is called “product backlog”.
  • During sprint planning activity, the development team extracts a small “chunk” of product features from the top of product backlog for development purpose. The temporary list of features to be developed is known as a “sprint backlog”. The team decides how to proceed with the development work.
  • The actual development is carried out in “short bursts” or activity known as sprints. The sprint has to be completed within a predetermined time limit. It cannot be extended or shortened. Traditionally it lasted from two to four weeks, but recent Scrum trends indicate it has shortened to last for seven to ten days. Each day before the sprint starts, a short meeting, not exceeding more than fifteen minutes, is held to “start” the day. The meeting is known as the “daily stand up” or the “daily scrum”.
  • The sprint should ensure that only shippable and bug free product features are developed. The development carried out by the team is verified by the PO and the stakeholders (if, and when necessary).
  • During the tenure of the entire Scrum project, the scrum master collaborates and helps the implementation process. He or she ensures that the team remains focused, and resolves difficulties and problems as and when they arise.
  • All Scrum events such as the sprint review meeting and the sprint retrospective meeting are to be conducted in an appropriate manner and at the correct time.
  • The entire Scrum process has to repeat itself until the entire product is manufactured through sustained product increment cycles – sprints.

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

Posted in Agile Scrum model, Scrum, Scrum Agile, Scrum Agile process, Scrum Framework, Scrum process, Scrum process model, scrum tool | Tagged , , , , , , , , , , , , , | Leave a comment

Main Differences Between Agile Scrum And XP Framework

Differences Between Agile Scrum And XP Framework

Of all Agile frameworks, scrum is the most popular one. Scrum framework is highly recommended for developing IT projects and it is so widely recommended for it that it is often confused with Extreme Programming or “XP” Agile framework, which is synonymous with software development. Both the frameworks are much similar, and to a person not conversant with Agile, both might appear to be the same at a first glance. While most Agile processes and events remain the same, there are some subtle differences between the two frameworks.

Sprint durations

Typically, in scrum, the sprint iteration can last from two weeks up to one month. In XP, the duration is much shorter, and generally lasts from one to two weeks. The sprint duration does not exceed two weeks in XP.

Committing the sprint backlog

One of the major differences, and an important one too, is how user stories are committed in the sprint backlog while implementing scrum and XP. In scrum, the sprint backlog is “owned” by the development team. Once the team accepts the sprint backlog, all the user stories in the backlog are “committed” for development purposes. The team is required to complete all the user stories stated in the backlog. Moreover, once committed, the sprint backlog cannot be “changed” while implementing scrum. If any new user story is required to be developed, it can only be included in the next sprint after a new sprint planning meeting is conducted. This is not the case with XP. The sprint backlog does not become “static” even after it is accepted by the team and the user stories are taken up for development. If required, based upon the feedback received from the stakeholders, a user story taken up for development can be replaced with another one having the same estimation in terms of story points. Therefore, the sprint backlog is not “committed” at any time in XP. New stories can be replaced in lieu of those currently existing in the backlog – something that is impossible in scrum. However, it is important to know that such a “replacement” of user story is only possible in XP before the particular user story is taken up for execution in the daily sprint. Once the development of a user story starts in XP, it cannot be replaced.

Determining the sequence while developing user stories

The role of the product owner remains common in both scrum and XP. The PO prioritizes the product backlog in accordance to the importance of user stories based upon the business values.  Feedback is availed from the stakeholders as to which of the user stories are more important and pertinent from the development point of view, and the PO categorizes the product backlog based upon the business values of the user stories. The similarity, however, ends there. In scrum once the user stories are prioritized and taken up for development during the daily sprints, the development team enjoys the autonomy of deciding how the user stories should be actually taken up for development during the daily sprints. The team can decide the order, or the sequence, in which it desires to develop the user stories. This does not occur in XP framework. The development team in XP has to strictly adhere to the priority of the user stories as decided by the PO and carry out the development in the same order of priority. In XP, the team cannot choose the order in which the user stories should be developed. It is decided beforehand by the PO or the client. The team is required to stringently follow the priority as stated in the sprint backlog.

In scrum framework, it is highly common for the team to start with the second-most-important user stories rather than the most important ones during the daily sprints. Larger user stories or “epics” are generally developed subsequently since they consume more development time. This is generally done to maintain the velocity during the scrum process, which is depicted in the burn down charts. It is important for the team to remain close to the “ideal” line so that the velocity is maintained at all times. Taking up easier user stories generally helps the team to remain consistent with the projected velocity. This is not possible to do in XP.

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

Posted in Scrum, scrum tool, sprint backlog, sprint duration, Sprint Planning Meeting, user stories, XP | Tagged , , , , , , , , | Leave a comment