Tuesday, 28 October 2014

Salient Features Of Scrum

Agile - The base of Scrum

Agile, and the path to Agility is now becoming a much sought after norm for many businesses across the world. There is a huge demand for understanding, and implementing, Agile based frameworks. Perhaps one of the main reasons why Agile is becoming increasingly popular is because consumer demands are changing radically and people now desire more. And, people are not ready to wait. They want products which offer good value for money, and that too with enhanced features. This has created a need to develop products which are:
  • Competitive
  • Feature rich
  • Quickly available
  • Fulfil specific end user requirements
Agile proposes to satisfy these requirements without adding on to the product costs.
The basic issue with all Agile frameworks such as Scrum is that they are – frameworks. They offer guidelines how the Agile process can and should be implemented in a project. For that, it becomes imperative to understand what a framework is, and how it differs from a methodology. Many individuals still feel Agile is a methodology and they could not be more wrong.

Agile methodology misconception

There is still a misconception regarding Agile – some people still tend to refer to Agile as a methodology. This is not true. A methodology offers a set of rules, principles, tools, or practices that can be used to conduct processes and achieve certain goals... Read more at Salient Features Of Scrum

Tuesday, 21 October 2014

Breaking Down The Agile Manifesto And Understanding It

The popularity of Agile frameworks, especially XP and Scrum, is increasing by the day, and more and more organisations are deciding in favour 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 organisations 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.
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.
We
To start with, the manifesto states “We” i.e. it emphasis that Agile is not a solo endeavour. It involves group activity and people have to collaborate while working, at every level, and at every instant. Development teams, project teams, and organisation 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 standardised 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
Agile focuses 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, analyse 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 honouring 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 functionalities 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 mould 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.

Friday, 10 October 2014

Scrum Product Owner Role And Sprint Planning Meeting Agenda

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

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


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



Tuesday, 7 October 2014

Scrum Product Owner’s Role

Agile professionals have often discussed what the exact role of a product owner should be in Scrum. What virtues should a product owner possess to be considered a “good” PO? The answers are many. And this is not surprising because Scrum is a framework, and its implementation in a project depends upon the requirements specific to the project. When requirements change, the role of the PO also changes. Therefore, it may not be possible to standardise the exact role a PO should play in a Scrum project.

A certain process flow remains common to almost all Scrum projects. The role of a product owner can be thought about in terms of what POs actually do in a typical Scrum project. Here are a few suggestions:


 Scrum Tool
Common role or activities of a Scrum product owner

·      Creating the product backlog as per the product vision seen by the stakeholders. Defining user stories having high business values in the backlog so the project “value” is constantly maintained.
·      Monitoring and tracking all Scrum activities. The role of a product owner may be difficult to act since a project might be demanding, and the product owner may have to cater to market related issues and still monitor the work carried out by the team. Balancing both the aspects can prove to be trying.
·      Make sure that the product backlog is kept refined at all times. Moreover, the product backlog should be accessible by the entire team.
·      Each product backlog item “PBI” should be properly stated and defined in the product backlog. The story description, appropriate business value, and the acceptance criteria should be stated precisely in the story card and explained to the entire team so the team members can develop effective stories and develop shippable product features.
·      To be available whenever needed, to remain present, and share information, knowledge, as well as expertise with other team members.
·      The PO responsibility should also include defining productive sprint goals just before a sprint commences.
·      A product owner’s responsibility should also include respecting and aiding everyone involved with the project and ensure the project is completed successfully.
·       Not try to influence the mind-set, or psyche of the team members regarding any issues and encourage the team to get involved in the project to achieve better productivity.

The role of a product owner can be a difficult one to play. Since the PO owns the project on behalf of the stakeholders, he/she has certain responsibilities towards them. The PO is also responsible for conveying the product vision as seen by the investors to the entire Scrum team and ensures that the product is actually developed in accordance to the vision.

Use free Scrum tool at Quickscrum.com

Wednesday, 1 October 2014

What is Role of Scrum Product Owner?

Several discussions have been carried out by Agile professionals regarding the Scrum product owner role. What virtues make a product owner an “ideal” one? How should a PO delegate authority? Should it be as per traditional management models, or should a servant-leader role be employed? How should the person handle stakeholders when there are issues? There are many questions. The debate can keep on extending indefinitely since newer “scaled” versions of Scrum keep on coming, and the PO has to change his or her role based upon the traditional, or scaled, version of Scrum the management decides to follow.

It would be more practical to concentrate upon some of the most important, and the most common, activities of a PO.

Scrum Product Owner Role

Read more at 

Scrum Product Owner Role

What is 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.

1st 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.

Sprint Planning Meeting Agenda

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.

2nd 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 carry out the actual development activity and create the stories in the sprint backlog. Generally, a Scrum team is “multi-talented” i.e. each team member possesses more than one type of expertise. However, it is important to know that this may not always be the case in all Scrum projects, since the product requirements and resources may vary depending upon the nature of product to be developed.

The team members – developers, programmers, designers, QA personnel, and technical writers – decide amongst themselves how the user stories should be split up into parts that are more “manageable”. Each such “part” is referred to as a “task” in Scrum. Tasks are developed to create shippable user stories. A developer can develop each task individually. Certain Scrum teams may even work in “pairs”. Members collaborate, and decide amongst themselves as to who should take up which task depending upon the experience and levels of expertise possessed by them. Once the tasks are “distributed” the actual sprint can begin.Read more at

Sprint planning meeting agenda

Why Agile Can Be 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 fulfil 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 fulfil 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:

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” Read more at Why Agile Can Be A Popular Software Development Framework?

Tuesday, 30 September 2014

Which Software Development Activities famous In The IT Field?

Individuals who are associated with the IT industry and computers generally use the term “software development” to describe the particular kind of work, or activity, they are currently doing or involved with. The terminology is very loosely used by most people, and can include almost any type of computer programming activity - including testing, debugging, document creation, deployment, developing and maintaining application frameworks, and even customising operating systems as well as platforms. There is a trend to mention one’s profession, or one’s mode of professional engagement as “software development” while the person may be working as an application developer, a Java or VBScript web developer, an Android or iOS mobile apps creator, or even developing scripts for WordPress based themes.

The fact is, the words “software development”are extensively used to refer to almost any type of IT related work, or activity, and generally denotes a development of “computerizable” code, in any way or manner, and of any “kind”. The following list provides a rough idea regarding the scope of development related activities in the IT field.

The list is periodically updated and keeps on evolving to include the new scope of software development.

Current list updated on 29th July, 2014.

Languages and scripts
Scripts and scripting languages:

HTML / HTML5 / DHTML / XHTML
Active Server Pages - ASP
VBScript
JScript and JavaScript
Personal Home Page - PHP
ColdFusion ( ColdFusion Markup Language - CFML)
Ajax
Ruby (Ruby on Rails)
Python
AppleScript
TypeScript
Job Control Language - JCL
Unix Shell scripts - ksh, csh, bash, sh, and others

Assembly languages:

Autocoder (used for programming mainframe systems such as IBM 1401 and 1440)
BAL (Basic AssembLer used for coding IBM System/360 and other mainframe systems)
FAP (Fortran Assembly Program for encoding IBM mainframes 709, 7090, and 7094)
GAS (acronym for GNU Assembler)
HLA (acronym for High Level Assembly)
MASM (acronym for Microsoft Macro Assembler)
MI (acronym for Machine Interface)
Motorola 68k Assembly (used for encoding Motorola 68000 family CPUs)
NASM (acronym for Netwide Assembler)
PASM
TASM (Turbo Assembler developed by Borland)

Authoring languages:

PILOT
Command line interface languages:

4DOS (extended command line shell for IBM PC family)
csh and tcsh (C-like shell developed by Bill Joy while at UC Berkeley)
CLIST
DCL DIGITAL Command Language (for DEC, Compaq, HP)
DOS batch language (standard batch language for IBM PCs and clones running under MS-DOS, PC DOS, and DR-DOS before Windows)
EXEC 2
JCL (punch card oriented batch language used in IBM Systems and 360 family mainframes)
REXX
TACL (acronym for Tandem Advanced Command Language)
Windows batch language (as understood by COMMAND.COM and used by accessing the Command Prompt)
Windows PowerShell

Compiled languages:

Ada
ALGOL
BASIC
C
C++
CLIPPER 5.3
C#
COBOL
Cobra
Common Lisp
Delphi
Fortran
Pascal
Visual Basic
Visual FoxPro
Visual Prolog

Educational languages:

Alice
Logo

Mobile operating systems and applications development

Android
Symbian
Apple iOS
Blackberry OS
Windows OS
Palm OS

Portals and websites
Web portals
Early types of portals, which originated, and are still being developed, ever since the World Wide Web or the internet started becoming popular amongst the masses. These portals and websites exhibit assimilated content, and typically display links supporting searching facilities.

E-commerce portals
E-commerce portals, also known as e-business portals help to share information with customers, partners, and suppliers. They generally support an online payment gateway or an “online transactions” processing component. The portals provide information, and in addition describe products and services. E-commerce portals try to increase customer-relationships and lower the product/service costs.

Self-service portals
These portals target employees, suppliers, and/or customers, and allow access to information which can aid the users in carrying out specific processes and activities.

Business intelligence portals
Also known as decision portals, business intelligence portals aid online users in making important decisions. Besides allowing users to submit query and avail reports across multiple data storages, business intelligence portals have many built-in facilities and tools that can help to generate targeted reports.

Collaboration portals
These types of portals provide information pertaining to geographically dispersed workforces, and help to interact with people and projects sharing a common cause or belief. Typically, collaboration portals provide generic tools supporting chat and white boards, in addition to threaded discussions and streams which help to share maps and documents.

Enterprise information portal
Generally of complex nature, enterprise information portals are highly tailored, and offer a unique experience to the visitors. Various legacy systems offer functionality to carry out predefined business related processes.

e-learning portals
Supporting online education, e-Learning portals aim to help and guide students by offering an organised and structured learning experience. These portals also offer testing facilities to evaluate your learning, and provide appropriate feedback to the students.

Communication portals
Communication portals, as the name rightly suggests, fundamentally support communications and messaging facilities through emails, voice messages, mobile linkups, web feeds, etc. in a manner that allows access from across multiple interfaces and locations. The users can configure how to use the facilities.

Social networking portals
These types of portals can be individual or groups based, and primarily aim to improve and enhance social communications between like-minded individuals, or those who share a common idea or belief. Typically, members subscribe and log into the portal and subsequently start sharing their ideas and thoughts with other member groups and individuals.
source:-

software Development Activities In The IT Field

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?

Tuesday, 16 September 2014

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

Friday, 22 August 2014

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

Tuesday, 12 August 2014

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