Showing posts with label sprint duration. Show all posts
Showing posts with label sprint duration. Show all posts

Monday 20 October 2014

Why Agile Can Be A Popular Software Development Framework

Agile A Popular Software Development Framework

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

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

1. Waterfall

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

2. Agile

A comparatively new “entrant” Agile has managed to find a special niche for itself in the IT development field over the years. The Agile framework was originally envisioned, and developed, to overcome the defects of traditional software project management methodologies and frameworks, which had failed to evolve “in the desired direction”, could not adapt themselves to the changing market trends, and offer reduced turnaround times. There are many reasons why “lightweight” Agile frameworks have become popular development platforms:
  • They support product development through “short bursts” of programming/development activity, generally lasting from two weeks up to one month. It is much easier to develop, test, and document smaller “pieces” of code, features, and functionality rather than entire projects. Individually developed features are later integrated to form the “complete” product. The frameworks primarily focus upon rapid delivery of “shippable” products and business value.
  • The client is actively involved with the team and the development process. Each feature is checked and “cleared” by the stakeholders before it is accepted as “Done”. This leads to increased customer satisfaction and enhanced user experience.
  • Potential pitfalls are identified well in advance, at a micro level, so it is much easier to control regression and reduce technical debt. Agile software projects generally help to earn good profit margins.
  • Agile frameworks support error detection and error correction processes. Technical errors are discovered early during the product development process, and dealt with effectively.
  • The frameworks provides an opportunity to carry out “retrospective” thinking, reflect in terms of where the project is heading, and what “more” could be done to improve the product development process.

Agile and the scope of software development

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

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

1. Clients and stakeholders engagement

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

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

2. Transparency and collaboration

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

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

3. Quick and predictable delivery

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

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

4. Predictable costs and work schedule

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

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

5. Support for “change”

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

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

6. Focusing upon the business value

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

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

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

Thursday 3 April 2014

The Role Of A Product Owner

The product owner in scrum
The product owner is a very important person in scrum. He or she owns the product on behalf of the company and the stakeholders. The person is responsible for the overall success of the project, and should oversee that the product development is carried out in a proper and planned manner as per the implementation rules suggested in scrum methodology. To carry out the responsibilities in an effective manner and make proper decisions at the correct time and in the correct manner, the product owner is endowed with certain powers, and authority, and the person should utilize those powers to ensure that the project is executed in a successful and desired manner. 
 
In real life, the role of the product owner varies in accordance to the nature and requirements associated with the project. Several factors such as the ongoing market conditions, the product development life cycle and stage, and the management influence how the product owner should set up priorities in a project. The participation of the product owner is very important in the initial stages of the scrum project when the product backlog is to be created and sprint durations are to be set up. The product owner’s work profile is not an easy one, especially if the organization is new to scrum, or if the individual lacks enough experience working as a product owner. 
 
What decides the role of a product owner in real life?
The best way of knowing about what a product owner should ideally do to be considered as a “perfect” product owner is to refer to the official scrum guide and pick up hints as to what the guide suggests. It is important to know that scrum is all about adaptation and being “agile” in its implementation. When scrum is to be implemented in a project, it should be done so in a manner such that the objectives are best fulfilled in the manner desired by the stakeholders. Many a times, the product owner has to change his or her working style and adapt to:
  • What the project demands in terms of responsibilities
  • The goals set up by the stakeholders
  • What the scrum team is capable of delivering
  • What the person is capable of delivering in terms of productivity and goal achievement on a personal level
When scrum is being implemented, the product owner is expected to engage himself or herself in a proactive manner and facilitate the working as and when possible. The person is generally expected to:
  • Collaborate closely with the team members on a consistent basis
  • Guide and direct the scrum team
  • Monitor and actively manage the product backlog
  • Answer questions and provide solutions to problems and questions when they arise
  • Provide appropriate and useful feedback to the stakeholders and the scrum team whenever required or demanded
  • Signing off work
In simple words, the product owner takes the back seat, decides what should and should not be done, and make sure the product is shipped at the correct time.

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Wednesday 2 April 2014

Sprint Review Meetings In Scrum – Objectives, Who Participates, And Why

The main purpose of a sprint review meeting is to:
  • Exhibit the development carried out by the team
  • Get a proper feedback about the work completed until date
  • Collaborate for a smoother functioning of the project
The reviews form a part of the inspecting and adapting process, which is one of the major advantages of scrum. Scrum methodology advocates self-learning. The scrum process supports several processes which help the team members to undertake self-correction activities, and adjudge where the project is heading. The sprint review meeting is conducted after a particular sprint is completed.
 
Sprint review meeting
Sprint reviews are informal in nature, and primarily held to display the work, in the form of user stories and development tasks, carried out by the team members during the sprint activity. The completed work is demonstrated to the stakeholders. The individuals who have invested funds into the project need to know about the status of the project and how much work has been done, so they can make proper plans to market the product. The review aims to update the stakeholders so they can get an idea regarding the quality and the quantity of development carried out in the project. It aids in increasing the user participation. The stakeholders can accept the work, or reject it in case they are not satisfied with it. They can also reject the work if the user stories fail to adhere to the acceptance criterions specified when the product items are created in the product backlog. 

The product owner represents the stakeholders’ interests. He or she remains present during the meeting and decides about the work. The stakeholders can attend the review meeting, but they are supposed to function as passive attendees, and not speak or volunteer opinions during the meeting.

Objectives of the review
  • Present the user stories completed during the sprint to the product owner
  • Have the user stories and tasks accepted as “Done”
  • Rejected and/or incomplete tasks should be transferred back to the product backlog
 
Who attends?
The product owner, team members, scrum master, and the stakeholders (only if interested – not mandatory)

Time boxed to
1 hour per week of the sprint duration/length decided (I.e. for a 2 week sprint, the meeting should be time boxed to 2 hours, for a 4 week sprint it should be 4 hours, and so on)
 
Roles played by the scrum team members while scrum is being implemented
Several individuals attend sprint review meetings, each having his or her particular interest in the project. The roles of the individuals attending the meeting are explained as follows:
 
Product Owner
The product owner accepts the ownership of the project as far as scrum is concerned, and acts as a “true” owner on behalf of the stakeholders. He or she takes up all the responsibilities, as well as the accountability of the overall team, and represent the entire project to the stakeholders. The person:
  • Presents the product increment activities
  • Provides an insight into the state of the ongoing scrum project
  • Generate a burn down chart displaying the work completed till date
  • Successfully and effectively deliver the views and opinions of the stakeholders to the team members

Scrum Master
The main, and the only important role of the scrum master while the project is underway, is to:
  • Facilitate the working
  • Act as a representative of the development team
He or she ensures that scum is properly implemented at all times, in the proper manner, and should make sure that the team members are collaborating while they work. Another role of the scrum master is to resolve difficulties and remove impediments as and when they arise.   
 
Scrum Team
The entire project is developed by the scrum development team. It is important to know the main difference between the scrum team and the scrum development team – the scrum team comprises of every member associated and involved with the project, while the development team consists only of those individuals who are directly associated with the development of the user stories and the tasks which constitute the product. Their responsibilities include:
  • Carrying out the development of user stories and tasks
  • Sharing ideas and concepts
  • Help each other out when a particular problem is faced by a team member during the sprint
  • Collaborate to get the most out of scrum 
 
Company Executives/Stakeholders
The stakeholders own the project. They benefit if the project is successfully completed, and suffer a loss in the event it fails to do so. The objective of the stakeholders is to:
  • Invest funds into the project
  • Appoint scrum leaders to execute the project
  • Monitor the development activity
  • Instruct the product owner to add more requirements or user stories if needed to complete the project
  • Eventually sell the product to make a profit

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Monday 31 March 2014

In Scrum, Can A Sprint Be Cancelled? If So, When?



Scrum framework and sprint
Scrum development is fundamentally about adapting to changes occurring during the product development cycle. Scrum levies a lot of significance to transparency, distribution of work, and incorporating changes even “late during the development stage”. Each individual associated with the implementation and working of the scrum framework is assigned a specific role. The person is strongly advised to perform within the boundaries specified by the role he or she is supposed to play, and not transgress the area of work under any circumstances. In scrum, the product owner too has a specific role to play, and is responsible for creating and maintaining the product backlog. The product owner has the final word while working out the list of requirements needed to develop the product – the user stories – which form the backbone of any product backlog. Each user story is further divided into individual tasks, which are taken up by the team members. These tasks are developed during the sprint activity. A sprint activity or simply the “sprint” is nothing but a “burst” of development activity undertaken by the team members, which generally lasts from two to four weeks as decided by the product owner. At the end of the sprint, a meeting is carried out which analyses how much development work has taken place, or how many user stories are successfully completed by the team members. So in many ways the sprint functions as the main essence, or the “heart” of the scrum process. Sprint plays an integral part in the scrum framework.

Can a sprint be terminated abnormally before it is completed?
Development teams are always instructed to complete their user stories as well as tasks well within the sprint duration. It is very important for the sprint process to be completed if the management is to achieve positive results out of scrum implementation. However, under some unusual or rare circumstances, sometimes sprints need to be “stopped” or terminated before it has a chance to run its full cycle. It is the product owner who decides if the sprint can or should be terminated or not.

Some of the reasons, which may induce the product owner to terminate the ongoing sprint, can be:

  • The stakeholders or the company management changes its priority regarding the product development
  • Market trends and/or changes make the current product development redundant or obsolete
  • A major technology change may introduce newer ways and methods of working
  • A better technical solution may offer a quicker and a more cost effective way of meeting the product development  
  • The management or the stakeholders may experience a financial crisis, or may not be able to financially support the development work
  • The launch of a new or better product may render the current development work superfluous and unnecessary
Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which
can help you in implementing scrum framework in your projects! 

Monday 24 March 2014

Importance Of A Sprint Planning Meeting In Scrum Framework



Significance of the sprint planning meeting
Whenever scrum is to be implemented for a project, user stories are carefully worked out, and a product backlog is painstakingly prepared in which user stories are properly categorized, and set up in order of their importance. The product backlog is prepared by the product owner, who is also responsible for ensuring that the user stories are properly taken up by the team members. The team carries out the actual development work during the sprinting activity. The sprint forms the backbone of all developmental activities associated with the particular project, and therefore it is required to be properly planned in order to get the most out of what scrum has to offer. For this, a special meeting is held before the sprint is to be executed. This meeting is known as the sprint planning meeting.
        
Who attends the sprint planning meeting?
Since sprint planning involves the formation of the sprint backlog (The list of user stories to be developed by the team members during the sprint. The product owner decides which stories are important, and recommends them to the team members who prepare a list of items which each team member is supposed to process and develop. This particular list is known as the “sprint backlog”). So the product owner has to remain present during the meeting. As the development is to be carried out by the team members, they too have to attend the sprint planning meeting. In addition, the scrum master is responsible to ensure that scrum is properly enforced, therefore it is also mandatory for him or her to remain present during the meeting.

The sprint planning meeting is attended by:

  • The product owner
  • Scrum master
  • Team members


What is the sprint planning meeting like?
The main purpose of the meeting is to create the sprint backlog with respect to its user stories and development tasks. The product owner has to decide which user stories are most important and which of them should be ideally incorporated into the sprint backlog. Once the sprint backlog is decided by the product owner, the team members have to decide how the sprint backlog should be processed for development purposes. So, mainly two aspects – the “what” aspect and the “how” aspect pertaining to the sprint are to be discussed and worked out during the sprint planning meeting. The meeting is generally divided into two parts – the first part catering to the “what” aspect, and the second part which deals with the “how” aspect.

The two parts are further explained as follows:

1. Objective definition – the “what” aspect  
In the first section or the initial part of the meeting, the product owner briefs about the user stories which are of highest priority and instructs the team regarding the acceptance criteria associated with the user stories, and what kind of functionalities are demanded by the stakeholders. The product owner does most of the talking and answers questions as well as queries put forward by the team members. The scrum master is a passive participant, but can also ask specific questions if he or she is not clear about a certain aspect regarding the implementation of scrum during the sprint.
 
2. Task estimation – the “how” aspect
During the second phase of the meeting, the “how” aspect is taken up by the team members. They segregate the user stories into individual tasks, and each member takes up a list of tasks to develop during the sprint. The tasks are unanimously selected depending upon the levels of expertise possessed by each team member. The main objective of the second phase of the sprint planning meeting is to ensure each team member has enough tasks on hand to last the entire sprint duration. Too many tasks should not be taken up so that the sprint cannot be successfully completed. Scrum makes it mandatory for each given task to be completed by each team member at the end of the sprint duration. At the same time, enough tasks should be taken up so that the team member does not run out of development work during the sprint.

Scrum emphasizes upon active participation and involvement of every team member. It is highly recommended that the scrum team should undertake a proactive approach regarding one’s involvement and responsibilities during the implementation of scrum. The sprint planning meeting should ideally be conducted keeping these principles in mind.   

Find out more, and benefit by downloading our free QuickScrum tool which can boost your profit margins!