How Can Agile Scrum Reduce Regression During Software Development?

For IT development companies, and organisations developing computer and digital-devices (smartphones, tablets, digital diaries, etc.) software projects, one of the most important, and also the most troublesome issue is encountering “bugs” or defects in the code functionality when a particular application, or a system, is deployed and used in a live environment. Software bugs can be very common. Ever since computers were designed in the yearly years, bugs have inadvertently, or otherwise, kept on troubling coders and project managers, and have tested their ingenuity to resolve them to the fullest extent possible. Ask any seasoned programmer - He or she will tend to initially confer, and eventually say that the word “Bug” is aptly named – It tends to “bug” you!

Etymology of the word “Bug”
It is interesting to know how the terminology “bug” was first coined, and used to describe a state of functioning in which an error, or a flaw in coding can lead to flawed results, or “outputs” in IT jargon. There are several stories as to how the terminology came into existence. A theory most subscribed to involves the pioneer programmer, Grace Hopper, who was a young Naval Reserve officer working on a Mark II computer at Harvard University. In 1944, she related an incident in which the computer had malfunctioned – an actual moth had, in fact, “managed” somehow to get itself embedded between two electrical relays, causing the computer to halt in its functioning. She explained that the cause of malfunction was a “bug,” which was later removed by a technician. The famous bug was exhibited by the Navy for many years, and is now owned by the Smithsonian Institute.

Bugs and software regression
In a broad sense, a software bug can be understood as an error, failure, flaw, or even a fault in the code designed to develop an application or a computer based system. Bugs typically create unexpected and incorrect results or outputs, which cause the functionality of the particular application to stop, or function in a manner other than so desired. Bugs generally arise owing to reasons such as:

Mistakes carried out while encoding a program
Designing improper code structure or logic
Utilising the functionality of the code in a manner other than that recommended
Technical errors in the code compilers and/or interpreting resources and agents
Of course, the above are not the only causes which give rise to bugs, however, they constitute the major reasons why bugs tend to occur in majority of the cases. When the numbers of bugs increase significantly, the overall functionality of the application may be compromised upon to a considerable level, rendering it useless and non-productive. This can cause severe financial loses, and even force businesses to face litigations from troubled end-users and consumers.

Broadly, the word “regression” means to return to a former, or a lesser developed state. So, how can regression be understood in terms of “software regression” pertaining to software development? In practice, developers write down, or generate code, to develop a particular functionality as requested by the end-user or the client. During the coding stage, the developer not only develops the code, but also checks it and ensures that it is working properly. This is a standard practice followed by most experienced programmers and developers. However, at times, the testing process may not be carried out properly, or the code functionality might work properly in most cases, but fail to work under certain circumstances and situations. A second scenario is the code may be developed and properly tested at the time of creation, and the application deployed in a successful manner. However, a newer version of the deployed functionality may be subsequently re-developed to include even more features and functionality, to replace the prior one. The reason could be a need experienced by end-users to use the functionality for a more specific purpose. The newer version may cause some of the older functionality to stop working. This, in a rough sense, can be understood as software regression.

For example, you could encode a program to display “Hello World” on the monitor. It might work perfectly, and display the message each and every time it is executed. Later on, the same code may be re-developed to accept the user’s name, and display it in lieu of “World.” The objective of the new code might be to display “Hello John” rather than “Hello World.” However, once the newer code is developed and deployed, it actually ends up displaying the user’s name only - “John” - instead of the actual greeting “Hello John.” In this case, some of the older functionality associated with displaying “Hello” in the greeting is curtailed due to some coding reason and “missed out” by the newer code. This is software regression.

Knowing a “bit” about what is Agile Scrum framework
Agile is a framework. It offers guidelines as to how software based projects can be effectively developed through consistent and sustained delivery of software functionality through short bursts of development activities known as “sprints.” Agile is based upon certain principles which suggest how the framework ought to be ideally understood and interpreted by people, and how the framework should function in an ideal working environment. One of the Agile principles state “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” To support this principle, Agile framework supports an iterative (repetitive) product incremental cycle (a process through which smaller components or parts of the actual product are individually developed, and later integrated to form the complete product). At the end of one product increment cycle (sprint), Agile events known as the “Sprint Review” and “Sprint Retrospective” are held to ascertain the reliability of the code functionality developed during the sprint, and whether it satisfies the acceptance criteria so it can be considered as “bug free” and fully functional. Agile promotes “shippable” product increments i.e. small pieces of code offering a certain functionality that is complete, perfectly functional, and free of any “manufacturing” defects.

It is worth knowing about the actual Agile process, events, roles, and artefacts which can help to eliminate bugs, and control the factors causing regression in software code. People new to Agile concepts and principles may find the framework difficult to understand. This article does not aim to educate the reader in Agile or Scrum framework. Rather, it aims to explain some of the important Agile characteristics which make the framework a very good choice for developing software projects. The objective is to describe how Agile can help to reduce regression levels during the development process. To understand how Agile can do this, it is important to know a “bit” about Agile first.

The product owner “PO” (Role)
He or she is the person who “owns” the project on behalf of the stakeholders or project owners. The person represents the interests of the stakeholders in the Agile project, and ensures that the project delivers a certain business value (importance in terms of market value and financial implications) at all times while the product is being developed. The individual is primarily responsible for the success or failure of the project.

The product backlog (Artefact)
It is a master list mentioning all features and functionalities to be developed in the software project, and to manufacture the software product in totality.

Product backlog item “PBI” or user story (Artefact)
In Agile scrum, the actual product is “broken down” into much smaller, manageable, and developable parts known as product backlog items “PBIs,” or user stories. Each developable sub-unit or product item exists independently in the backlog. Moreover, each PBI is defined to include:

An index or a reference number to uniquely identify the PBI
A description stating the functionality to be developed
An explanation describing what the functionality is supposed to deliver, how it is to be delivered, and why it is needed
A list of acceptance criteria which needs to be satisfied for the PBI to be considered as “perfect” and “complete”
A short explanation describing what must be “done” for the PBI to be considered as “shippable” and ready for immediate use

Sprint planning meeting (Event)
The iterative product development cycle (sprint) is initiated by an Agile event known as “sprint planning.” This meeting is important from the development point of view. The meeting is held in two parts. In the first half, the PO selects important PBIs or user stories for development purposes from the product backlog, and a temporary list known as a “sprint backlog” is prepared to hold the user stories for development purpose. The PO then explains to the development team how the stories should be developed, and what activities team members should carry out to make the development “acceptable.” The acceptance criteria is properly explained to the team, so each developer becomes familiar as to how the actual development activity should be carried out, and what the management expects out of the proposed development.

In the second half of the meeting, the development team discusses how user stories should be distributed amongst the developers in the team. Stories are generally distributed based on the expertise and skill sets possessed by the developers. Individuals are assigned development tasks based upon their familiarity with the development process and their experience levels.

Sprint backlog (Artefact)
It is a temporary list created by the PO during the sprint planning meeting to hold the PBIs, or user stories, for development purpose. In Agile, development is always carried out in short bursts of activity known as sprints, and at any given time, a small subset of the product is actually developed. Unlike the traditional waterfall method, development is never carried out in “whole.” The entire sprint backlog is processed for development during the sprint.

Daily sprints (Event)
The “heart” of all Agile frameworks, daily sprints form the base of all development activities. Sprints generally last for two weeks, but can extend up to a maximum of one month. Agile sprints are fundamentally product increment cycles which keep on repeating until the entire product is developed in bits and pieces.

The sprint review (Event)
It is an Agile event held immediately after a particular sprint, or a product increment cycle is completed, and a certain code functionality in the form of user story is developed by the team. The meeting is headed by the Product Owner who verifies the development, and ensures that the user story satisfies the definition of “Done” as mentioned in the PBI. If the user story fails to satisfy the acceptance criteria so stated, it is sent back to the product backlog for re-development. If it is accepted by the PO, the user story is presented to the stakeholders in the succeeding sprint review event for their acceptance and opinions.

Sprint retrospective (Event)
Held immediately after the sprint review event, the stakeholders preview the user stories developed by the team. The stakeholders offer their opinions regarding how much of business value the user stories actually offer after their development, and whether the stories can be, in fact, considered as “shippable.” The main purpose of the retrospective is to reflect upon what mistakes occurred in the Agile project in the past, and what needs to be learnt from prior mistakes. The retrospective offers an opportunity for the Agile team to communicate with the end-users and project owners, and to get “first hand” information as well as knowledge as to what the stakeholders actually need in their project, and how they had actually envisioned their project at the time of its inception.

How can Agile Scrum framework help to reduce or eliminate bugs and software regression?
Software regression is identified if it exists in the code functionality, checked, rectified, and re-tested during the Agile development process. This is how it happens.

Starting with the software development process using Agile
In Agile, the actual development starts with the creation of the product backlog. Based upon how the stakeholders and project owners have envisioned the software project, and what they desire in terms of product functionality, the PO initially “breaks down” the entire project into PBIs or user stories, which are small, individually developable functional units. Once the master list or the product backlog is created, the PO assigns a business value to each PBI, so that important user stories having a higher “market value” can be developed first. The PO than proceeds to conduct a sprint planning meeting which is attended by all. In the sprint planning meeting, the PO selects some of the important PBIs from the top of the product backlog, and transfers those stories to the sprint backlog so the development team can start with its coding activity. It is important to know that developers and programmers only develop those user stories which have been transferred to the sprint backlog, and none of the other PBIs stated in the product backlog. The developers then break down the PBIs into individually developable even smaller tasks and distribute them amongst themselves. Each programmer or developer prepares a smaller list which includes all tasks to be developed by him or her during the sprint.

Carrying out the actual software development
The actual product development is carried out through sprints. During the sprint, each developer takes up tasks allotted to him or her, and proceeds with their development. At a time, one task is taken up for development. Once the task is completed, it is marked as “Completed” and another task is subsequently taken up for development. The process is repeated until all the tasks are developed. Once a particular task is completed, it is tested for its reliability, consistency, and accuracy by team members specially appointed to carry out the testing process. Some Agile processes maintain a separate team for carrying out the Q.A. related activities. Each task is painstakingly checked for any errors arising through improper coding practices, wrong usage of coding language, flawed design, and other regression related parameters. Agile teams can also use specially developed regression testing software to identify any flaws in the coding, designing, or functionality aspects. Once the regression checking is over, the user story is verified whether it fulfils the benchmark and acceptance criteria mentioned in the PBI. After the story is thoroughly checked, it is marked as “Completed” and its status updated in the Agile process flow. It is important to complete all the tasks allotted to the team members during the sprint.

After the development activity
After all user stories have been developed by the development team during the sprint, an Agile event known as the sprint review is held to present the development carried out to the PO. During the sprint review, the PO scrutinises each user story and re-verifies whether they fulfil the acceptance criteria, and whether they, in fact, meet the definition of “Done.” If any user story fails to satisfy the PO, it is transferred back to the product backlog from where it may be taken up for re-development at a later stage. Only bug free, well documented, and “shippable” user stories should be accepted as “final” during the sprint review. The objective of the event is to check for any regression related issues at a “micro” level.

Once the sprint review event is over, another Agile event known as the sprint retrospective is held to further ascertain whether the user story functionality is acceptable from the market point of view. The stakeholders, project owners, end users, and other technically oriented staff members attend this event. The user story functionality is demonstrated to the participants, who minutely scrutinise the functionality aspects and working to find any flaws or incorrect functioning of the user story. The participants also determine how much worth the functionality is from the saleability and market point of view. Once the stakeholders are satisfied with the results, the user story is accepted as “Done.” The aim of this event is to check for regression related issues at a “macro” level.

Agile Scrum and software regression
Each task, when completed by the team during the daily sprint, can be individually tested for bugs, design flaw, and regression. In Agile, the user story cannot be accepted until it fulfils the acceptance criteria and meets the benchmarks. At the time of development, the developer initially checks the user story for any bugs, or errors of any kind. Once the development team Okays the functionality, it is checked and verified again by the PO. POs are usually experienced Agile professionals, and have the knowledge, as well as the ability to find any bugs or flaws overlooked by the team. This is how bugs are eliminated at a micro level. Once the PO acknowledges the user story, it is exhibited to the stakeholders who are familiar with the market trends and conditions, and know what kind of functionality a particular user story should offer to satisfy the end user’s requirements. They again check the functionality from the end user’s point of view, and if it does not proffer to fulfil what the end users need, they reject the user story. When any user story reaches the sprint retrospective stage, it will not possess any bugs or coding errors, which are detected in the preceding micro level stages. The development is checked at a macro level during the retrospective, and accepted by the end users.
Source:-  How Can Agile Scrum Reduce Regression During Software Development?

Scrum Tool

QuickScrum helps to unlock the power of Agile Scrum into your projects – whether you are  a “seasoned” Agile professional or a novice - just starting with Scrum – you can get started with  Scrum implementation and get your projects “going” right away! The Scrum tool plays an indispensable part in planning and developing your software projects. It can help you: Create and estimate user stories Effortlessly create and maintain product backlogs Define and design your sprints Identify team progress and velocity through dynamically generated burndown and  velocity charts Visualise the entire team activity on a “single” platform Avail customised reports to get an insight about your project’s status. QuickScrum Scrum tool advantages The tool offers many benefits and is a “must have” for all Scrum whiteboard users. The tool  offers several facilities and features that are not found, and not possible to have while  using a traditional whiteboard. It offers an “automated” Scrum implementation solution for the  entire team. Search anything at your fingertips A trademark feature of the tool, very few other Scrum tools offer a facility wherein you can  search for any type of project related information without leaving your current page. Envisioned  and designed specially to aid the Scrum team, the search features ensure you have quick and  easy access to any aspect or information pertaining to your ongoing project. Find, check, edit,  and delete whatever you need to – instantly!   Manage product backlogs of any size and complexity Product backlogs form the “heart” of a Scrum based software project. The tool supports creation  of new user stories, their modification, and removal. It is very easy to create, search, and list  out user stories based upon your specific searching criteria. The product backlog  management supports drag-and-drop features which help in the backlog grooming activity.  It is easy to carry out the backlog refinement sessions with the entire team using the  backlog management features. What’s more, you can create and maintain product backlogs  of any size and complexity.   Plan multiple sprints simultaneously Multiple sprints can be designed and planned on a single page. Access Scrum taskboard from anywhere Very essential for distributed or disjoint development teams, the tool offers a common, shared  access to all team members. Each member can log on and view instant updates on the taskboard.  The taskboard helps to foster collaboration through live updates of activity carried out by other  team members. The taskboard features can be accessed from anywhere. Live Burndown charts Generate burndown charts that display the most current team progress. Compare ideal team  progress with your current team velocity and monitor projects in a dynamic way. An essential tool  for product owners and scrum masters to keep track of current team activity and progress. Instant team activity log Whatever activity you do – whether the tool users create a new user story, add, or update tasks  – everything is “logged” and displayed “live” in the activity log section of the tool. See what  other team members are currently up to and “doing” in the tool. Detailed velocity charts Informative and visually appealing velocity charts exhibit the current team velocity. Resources workload and summary The QuickSCrum tool displays tasks linked to individual resources and their task statuses, in  terms of time available, associated with each team member. The resource workload summary  is exhibited, so it can be identified how much additional work can be taken up and completed  by the programmers.Read more at Scrum tool

Main Differences Between Agile Scrum And XP Framework

Of all Agile frameworks, scrum is the most popular one. Scrum methodology 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 a
nother 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. Read more at http://goo.gl/35Yq67

Subscribe Free scrum tool from Quickscrum.com

How Can Agile Scrum Reduce Regression During Software Development?

For IT development companies, and organisations developing computer and digital-devices  (smartphones, tablets, digital diaries, etc.) software projects, one of the  most important, and also the most troublesome issue is encountering “bugs” or defects in  the code functionality when a particular application, or a system, is deployed and used in  a live environment. Software bugs can be very common. Ever since computers were  designed in the yearly years, bugs have inadvertently, or otherwise, kept on troubling  coders and project managers, and have tested their ingenuity to resolve them to the  fullest extent possible. Ask any seasoned programmer - He or she will tend to initially  confer, and eventually say that the word “Bug” is aptly named – It tends to “bug” you! Etymology of the word “Bug” It is interesting to know how the terminology “bug” was first coined, and used to  describe a state of functioning in which an error, or a flaw in coding can lead to  flawed results, or “outputs” in IT jargon. There are several stories as to how the  terminology came into existence. A theory most subscribed to involves the pioneer  programmer, Grace Hopper, who was a young Naval Reserve officer working on a  Mark II computer at Harvard University. In 1944, she related an incident in which  the computer had malfunctioned – an actual moth had, in fact, “managed” somehow  to get itself embedded between two electrical relays, causing the computer to halt  in its functioning. She explained that the cause of malfunction was a “bug,” which  was later removed by a technician. The famous bug was exhibited by the Navy for  many years, and is now owned by the Smithsonian Institute.  Bugs and software regression In a broad sense, a software bug can be understood as an error, failure, flaw, or  even a fault in the code designed to develop an application or a computer based  system. Bugs typically create unexpected and incorrect results or outputs, which  cause the functionality of the particular application to stop, or function in a manner  other than so desired. Bugs generally arise owing to reasons such as: Mistakes carried out while encoding a program Designing improper code structure or logic Utilising the functionality of the code in a manner other than that recommended Technical errors in the code compilers and/or interpreting resources and agents Of course, the above are not the only causes which give rise to bugs, however, they  constitute the major reasons why bugs tend to occur in majority of the cases. When  the numbers of bugs increase significantly, the overall functionality of the application  may be compromised upon to a considerable level, rendering it useless and  non-productive. This can cause severe financial loses, and even force businesses  to face litigation from troubled end-users and consumers. Broadly, the word “regression” means to return to a former, or a lesser developed  state. So, how can regression be understood in terms of “software regression”  pertaining to software development? In practice, developers write down,  or generate code, to develop a particular functionality as requested by the  end-user or the client. During the coding stage, the developer not only develops  the code, but also checks it and ensures that it is working properly. This is a  standard practice followed by most experienced programmers and developers.  However, at times, the testing process may not be carried out properly, or the  code functionality might work properly in most cases, but fail to work under  certain circumstances and situations. A second scenario is the code may be  developed and properly tested at the time of creation, and the application  deployed in a successful manner. However, a newer version of the deployed  functionality may be subsequently re-developed to include even more features  and functionality, to replace the prior one. The reason could be a need  experienced by end-users to use the functionality for a more specific purpose.  The newer version may cause some of the older functionality to stop working.  This, in a rough sense, can be understood as software regression. For example, you could encode a program to display “Hello World” on the monitor.  It might work perfectly, and display the message each and every time it is executed.  Later on, the same code may be re-developed to accept the user’s name, and display  it in lieu of “World.” The objective of thenew code might be to display  “Hello John” rather than “Hello World.” However, once the newer code is developed  and deployed, it actually ends up displaying the user’s name only - “John” - instead  of the actual greeting “Hello John.” In this case, some of the older functionality associated  with displaying “Hello” in the greeting is curtailed due to some coding reason and  “missed out” by  the newer code. This is software regression.  Knowing a “bit” about what is Agile Scrum framework Agile is a framework. It offers guidelines as to how software based projects can be  effectively developed  through consistent and sustained delivery of software functionality through short bursts  of development activities known as “sprints.” Agile is based upon certain principles which  suggest how the framework ought to be ideally understood and interpreted by people,  and how the framework should function in an ideal working environment. One of the  Agile principles state “Our highest priority is to satisfy the customer through early  and continuous delivery of valuable software.” To support this principle, Agile  framework supports an iterative (repetitive) product incremental cycle  (a process through which smaller components or parts of the actual product are individually  developed,and later integrated to form the complete product). At the end of one product  increment cycle (sprint),Agile events known as the “Sprint Review” and “Sprint Retrospective”  are held to ascertain the reliability of the code functionality developed during the sprint,  and whether it satisfies the acceptance criteria so it can be considered as “bug free”  and fully functional. Agile promotes “shippable” product increments i.e. small pieces of  code offering a certain functionality that is complete, perfectly functional, and free  of any “manufacturing” defects.It is worth knowing about the actual Agile process, events,  roles, and artefacts which can help to eliminate bugs, and control the factors causing  regression in software code. People new to Agile concepts and principles may find the  framework difficult to understand. This article does not aim to educate the reader in  Agile or Scrum framework. Rather, it aims to explain some of the important Agile  characteristics which make the framework a very good choice for developing software  projects. The objective is to describe how Agile can help to reduce regression levels during  the development process. To understand how Agile can do this, it is important to know a  “bit” about Agile first. The product owner “PO” (Role) He or she is the person who “owns” the project on behalf of the stakeholders or project  owners.  The person represents the interests of the stakeholders in the Agile project, and ensures  that the project delivers a certain business value (importance in terms of market value  and financial implications) at all times while the product is being developed. The individual  is primarily responsible for the success or failure of the project. The product backlog (Artefact) It is a master list mentioning all features and functionalists to be developed in the  software project,and to manufacture the software product in totality. Read more at http://goo.gl/Gy8PXu

QuickScrum Tool

Follow my blog with Bloglovin

Is Agile Scrum suitable For Software Development?

The scope of development in the software/IT field

People and individuals associated with software development and the IT field like to use the term “software development” to describe their particular field of work and professional involvement. The term “development” is very widely used to describe a host of activities catering to the IT field. It can range from developing code for applications and systems, to developing mobile applications for mobile operating systems such as Android, iOS, Symbian, Windows OS, etc. (visit http://en.wikipedia.org/wiki/Mobile_operating_system), “manufacturing” gaming software using scripting languages like Ruby, AGSScript, Lua, Marathon markup language, Ada, C++, C#, D, Lisp, Mercury, Pascal, Perl, Python, Scheme, JavaScript, Java, VBscript, EDL, etc., (visit http://en.wikipedia.org/wiki/List_of_programming_languages) carrying out web development using HTML, CSS, PHP, Joomla, DotNetNuke, Java, etc., and even developing entire operating systems for tablets and PCs  (visit http://en.wikipedia.org/wiki/List_of_operating_systems, to know more about operating systems). The fact is as on today, the terminology “software development” is extensively used to mention almost any type or activity associated with the programming and development of “computerizable” code of any type, in any way, or manner. When a particular methodology or framework is used to develop computerizable code and create software projects, it is important to ascertain whether the scope of development includes the specific activity you’re currently involved or associated with. Software development and projectmanagement frameworks such as Agile have the potential to develop successful IT related projects involving the vast majority of development platforms and operating systems.

What is Agileframework?

While explaining Agile in a simple and straightforward manner, it can be best understood as a collection of project development methodologies and frameworks, of which any framework or methodology can be used in a successful manner to dynamically develop projects of almost any type and nature, including software development projects. The framework is based upon iterative and incremental development, in which self-organised and self-managing development teams understand, plan, and develop projects under the supervision of a project leader, and offer productivity in the form of short bursts of development cycles (iterative development) known as sprints. A unique feature of all Agile frameworks is that the development carried out by the team is “shippable” in nature i.e. the code developed during the product development cycle is independent, testable, verifiable,  documentable, and ready for deployment after it is stringently checked for any “manufacturing” defects.

A second, highly important feature of Agile development is that individuals “owning” the project are closely linked with the approval of development carried out by the team. A particular “code” or “piece” of functionality is checked for regression after it is developed, and subsequently presented to the stakeholders and project owners. They ascertain the development carried out, and clear it as “OK” for future integration into the actual product. This leads to a successful development of software projects, since the management is always aware about what functionality is currently being developed by the team, and up to what extent it satisfies the project objectives. If the project owners feel the productivity offered by the team is not up-to-the-mark, or fails to satisfies them in terms of business value (how much important the code or functionality is from the market point of view, and how much it is worth from the financial point of view) offered by the functionality, they can reject the entire functionality and instruct the project manager to redevelop the particular script or code, based upon a new set of inputs and requirements recommended by them. This ensures that the software project always “maintains” its business value at all times, even while the product is being currently developed.     

A third important feature of Agile framework is that all activities in the project are “time boxed”, and therefore, have to be completed within a predetermined time period. In an Agile project, each activity is time bound. All development related activities are “configured” to suit the unique project needs, and a duration “affixed” to them so they can be completed within a stipulated time. This ensures that the project does not “drag-on” and extend indefinitely. The development costs incurred while the project is being developed can be properly and “profitably” controlled, so that the project does not become “too” expensive and difficult to afford financially.

Agile principles and features

Agile framework differs drastically when compared to traditional linear or Waterfall methodology. In Agile, project development is carried out in short bursts of activities rather than in stages that have to be “completed” one after the other.

The main Agile features include:

·  Cross-functional development teams consisting of developers, programmers, testers, QA personnel, technical writers, system analysts, etc. all work together as a single composite team through collaborative efforts, offer and share ideas, and help each other during the development process.

·   Working in short, fast-paced development cycles, with focused objectives – Iterative development.

·  Shippable productivity at the end of iterative development cycles – Incremental development. The functionality keeps on “growing” through development cycles until the entire application, system, or product is developed.

·   Human communications and involvement takes precedence over management authority and delegation of work.

·   Total transparency and visibility of the team progress to project owners, stakeholders, and end users.

·    Feedback and suggestions help to self-correct and offer new ways and means to carry out quicker, more efficient, and reliable development.

An important feature of all Agile frameworks is that the frameworks are independent of the nature of project to be developed i.e. the framework is not dependent upon the platform or environment used to develop the particular software project. The architecture or design can vary, and could be anything. The important aspect is that an Agile framework has to be implemented in the project first, and its benefits availed subsequently. Please visit http://en.wikipedia.org/wiki/Agile_software_development.

What is Agile scrum?

Scrum, briefly, is a “light weight” Agile framework, used extensively for developing and delivering “workable” software products, very often, and on a consistent basis. The software products can range from the development of new web processes and systems, gaming solutions, plugins, mobile apps, ecommerce websites, corporate portals, development of WordPress themes, RAD (Rapid Application Development) projects, OOPs (Object Oriented Programming) projects, CAD/CAM drafting solutions, port programming and configuration utilities, web development and platform interfacing solutions, etc. Scrum adheres to all Agile principles and features discussed above since the framework is “inherited” from Agile itself.

Scrum offers a new, and a better way of managing software projects. There are many technical reasons why Scrum is popular and why many Fortune 500 companies prefer to use the framework for their project development purposes. While being introduced to Agile Scrum, a question that inadvertently comes to one’s mind is why is Scrum so popular? Why is there so much “hype” about Scrum? Does Scrum offer a magic formula, which can work wonders for your project and software development? Why should an organisation that has been following a particular development methodology, and feels comfortable doing so, should change over to Scrum? There is a separate article which deals entirely with why you should opt for Scrum. The point is, this article focus upon explaining Scrum to individuals who are new to the topic, and have absolutely no idea what the framework is all about, and what it can “do” for you. Efforts have been made to explain that Agile Scrum is applicable to almost any kind of software development, and possesses certain features which make the framework very popular as well as “powerful”.    

How does Scrum work?

The actual Scrum process can prove to be difficult to understand, at first, for Scrum beginners. Even though Scrum implementation is not difficult, people need to understand and familiarize themselves about what is product increment, and how it actually occurs during the Scrum process. The second aspect is getting to know about Scrum events. The special meetings, known as “events” are important for monitoring the development activity, and analysing the reliability and effectiveness of the functionality developed by the team. They also help to solicit feedback from the team members as well as the project owners so that the business value of the project is not affected, and maintained at all times – even while the product is being developed. It is worthwhile to get an “overview” of the process first.  

1.    Project conception - An idea!

All projects, whether involving software development, or otherwise, start with an “idea”. Projects are developed out of needs. A project is planned to fulfil a particular requirement or achieve a certain objective. Moreover, each project results into “something” within a specific time frame – a project cannot extend indefinitely. It is important here to differentiate between a “project” and a “program”. Programs are generally long termed, and can even last for years, unlike projects which have a relatively short life span and last for a brief period, ranging from a couple of months to even a year.

Typically, a person, or a group of individuals realise it is worthwhile to put in efforts and resources, and develop “something” so that “another thing” can be easily fulfilled or availed. The “something” is the product, and the “another thing” is the solution that the project is supposed to provide. This stage of project development involves a lot of discussion and brain storming sessions, where the product is envisioned and “though over”.

Scrum does not figure during this stage. However, the vision seen by the project owners, can, or may, affect the manner in which Scrum is implemented in theproject, in the future. This is because the nature of product to be developed may require Scrum to be configured in a certain manner to obtain positive results from the project. 

2.    Project release – Getting started with the software project

Once the project is “thought about” the next logical step is to work out the nitty-gritty concerning the project dynamics – the objective of the project, the product definition, how the project should ideally deliver the product, in what manner, what should be the “strength” of the team, how many team members, etc.

Scrum development process does not come into the picture even during this stage. The documentation pertaining to the project is created and “everything” concerning the product to be developed is finalised – in black and white. Scrum does not advocate extensive documentation. You do not have to prepare detailed system flow diagrams and extensive design structures to get started with Scrum development. A basic idea will suffice, and you should only spend that much time and efforts which can get you “started” with the actual development activity. Just enough information and specifications to develop some of the most important product features.     

The project release is attended by the “Product Owner” – the person who functions as a project manager in the Scrum project, the Scrum Master who overseas that Scrum is properly implemented and followed by the team while the project is being developed, and the stakeholders or project owners who actually sponsor the project. 

3.    Creating the product backlog (Product Features List) – Defining the product features and functionality

The Scrum development process starts with the creation of a master list containing all features and functionality required to create the product in totality. In simple terms, the entire product, currently existing on paper as “imagined” by the stakeholders and project owners, is “broken down” into its constituent parts, consisting of individual features and functionality. The product is thoughtfully, and systematically, broken down such that each individual component can be individually developed, tested, and eventually integrated with other software components or functionality developed by the team over the days. Individually developed features and functionality can eventually “give birth” to a working product when integrated or assembled later on.

Each individual feature or list item is known as a “Product Backlog Item” or a “user story” in simple language. Therefore, the product backlog or the master list is fundamentally composed of product backlog items or user stories. The user story represents a product feature, and is individually developed by the team members during the development process – the daily sprints. Each story can be minutely defined. The description, acceptance criteria (Points which need to be “fulfilled” or satisfied before which the story can be considered as successfully developed), its importance in the project, and the manner in which it is supposed to be integrated into the final product, etc. are mentioned for each user story.

Once the feature list is created, it is arranged depending upon the importance of each user story in the product backlog. Important user stories are arranged in the “top” portion of the list, lesser important stories in the middle, and the least important features and functionality in the bottom portion.    

4.    Sprint planning meeting – Planning how to develop the product features

The product backlog functions as the main “backbone” of all development related activities in Scrum. Once it is “developed” by the product owner and the stakeholders, the actual development activity can start. A special meeting known as a “Sprint Planning” meeting is held to initiate the development activity. The meeting is attended by the entire development team, in addition to the product owner “PO” and the scrum master “SM”.

The meeting is held in two parts. In the first part, the product owner selects some of the most important user stories or product features from the top of the product backlog, and transfers them to a temporary list known as a “Sprint Backlog” for development purpose. During the meeting, the product owner takes the opportunity to explain each user story in details to the team members – how user stories should be ideally developed, and what activities the team should carry out so that each story can be marked as successfully completed.

During the second half of the meeting, the development team analyses the sprint backlog and distributes each story to individual team members. In practise, the team members unanimously decide as to who should take up which story depending upon their development skills and experience levels. Simple and easily developable items are given to less experienced or “fresher” while difficult, or more complex stories are taken up for development by more experienced and senior programmers or developers.         

5.    The daily sprints – Developing the product features

This is the main area of activity in Scrum. The entire product is developed in “bits” and “pieces” through the daily sprint cycles. A sprint cycle is nothing but a collection of working or “development” days during which the team members actually sit in front of a PC and develop the functionality or product features. The sprint cycle is time boxed and should not extend its deadline.

Each item included in the sprint backlog during the sprint planning meeting should be developed while the sprint is currently underway. A brief meeting known as a “Daily Scrum Meeting” is held for a maximum of 15 minutes each day before the team members start with their work. The purpose of the meeting is to get an idea regarding how much work has been completed by each member the day before, and what each member proposes to do “today”. If a team member is facing any issues or problems, it can be mentioned during the meeting, and the scrum master will ensure that the issue is quickly resolved.   

In Scrum, the daily sprints can typically last from 2 weeks up to a maximum of one month. The duration of the sprint is decided during the second stage - the project release - and it should not be extended under any circumstances - even if any of the user stories in the sprint backlog have not been developed, or whose development is incomplete.  

6.    Sprint review – Checking and verifying productivity (Is the development OK?)

Scrum emphasises upon the development of “shippable” functionality at the end of daily sprint cycle. Each user story developed during the daily sprint is checked by the product owner and verified for its reliability, acceptance levels, and whether it is “bug free”. In Scrum, it is very important to deliver error free features – each user story should be properly tested for any regression, and whether it satisfies the acceptance criteria linked with its development. 

Just after the daily sprint cycle ends, a meeting is immediately held to review the development carried out by the team. It is important to differentiate between the daily sprints and the sprint cycle. The daily sprint is the development activity carried out by the entire team on one particular working day. Many such “daily sprints” combine to form the “Daily Sprint Cycle”, also known as the “product incremental cycle” in Agile. The meeting is held at the end of the product incremental cycle – the daily sprint cycle. It is primarily attended by the product owner, the scrum master, and the team members. It is not mandatory for the stakeholders to attend this meeting. They can chose to attend it if they so desire.

The main objective of this event, or rather the meeting, is to check whether the features have been developed by the team as per the production plan, and if the functionality has any “manufacturing” defects. Each feature should be fully tested for any flaws by the team before presenting it in this meeting. The product owner verifies if the feature is error free and checks if it satisfies the acceptance criteria linked with it. It is a kind of “final” check carried out before presenting the development to the stakeholders and the project owners in the subsequent sprint retrospective meeting. During the meeting, the product owner instructs the team how it can improve its working and offer even better productivity by employing more efficient programming practices and standards.

7.    Sprint retrospective – Finalising product functionality and contemplating about further improvement

Agile Scrum advocates client participation. The client is a very important entity in Scrum, and has the final say as far as the development of product features is concerned. The Agile manifesto primarily stresses upon client participation and delivery of time bound product increments because these two aspects are very important for developing successful projects. A “satisfied” client often “comes back” to develop more projects since successful projects help the client to earn higher profit margins.

The retrospective provides an opportunity for the entire team to demonstrate its productivity in front of the stakeholders and clients. In addition to the product owner, scrum master, the development team, the meeting may also be attended by end users, technical staff personnel, vendors, distributors, and even other employees since the main purpose of the meeting is to avail feedback from individuals and entities closely linked with the market, and who have sound knowledge regarding what product features are likely to “score” in the market once the product is launched, and what can aid the product in “selling”.

The retrospective also offers a chance for the entire team as well as the client to reflect upon the development process, and discover what more could be done to make the product better. Discussions are carried out to ascertain the rate at which user stories are currently being developed by the team, and what new processes or methods need to be introduced to quicken the process.

           Subscribe Free scrum tool from Quickscrum.com