Showing posts with label backlog grooming session. Show all posts
Showing posts with label backlog grooming session. Show all posts

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 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. A framework, on the other hand, is a loose structure that leaves enough room for other tools and practices to be included, and only provides the process required. In simple terms, a methodology is like a doctor’s prescription – you have to “take” it as per instructions provided, while a framework is like trying out home remedies – you know what can be done to achieve a particular objective, but it is up to you how to implement the remedy, and when to implement it. An Agile framework has to be implemented in a project to be successful, and there are no specific rules about how to do it. You have to follow certain guidelines and configure your project to function as per the rules specified in the framework. This is very much the case with Agile. Agile is a framework.

Agile Scrum salient features

Of all Agile frameworks, Scrum and Extreme Programming “XP” are the most popular. Even though Scrum framework is more generally used for developing software projects, it can also be used for developing non-IT projects. Scrum constitutes a collection of ideas and rules pertaining to effective project management. The framework supports collaboration and self-organisation. The team members work jointly and develop the project. They collaborate and share their ideas and findings. Scrum teams self-manage their activities. The most important aspect of Scrum is that all activities are time boxed. The client receives working versions of the product features on a continued basis through product incremental cycles – sprints – at regular intervals ranging from a week up to a maximum of one month. Cycles keep on repeating until all product features are developed and the product is ready.  

A unique aspect about Scrum is that the framework has a capability of adapting itself to changing market conditions, and incorporates those changes in the product development cycle even late during the development process. The Scrum process focuses upon responding quickly and efficiently to changing environments and assimilating those changes in the product design. The client benefits though the development of a product that is in tune with the most recent market demands. Moreover, participation from the end users and incorporating their suggestions while developing the product features further ensures that the product developed is most likely to assume a high business value or worth.  
  • Scrum - an agile process – focuses upon delivering high business values to the client in the shortest time possible.
  • It supports rapid and repeated inspection of the actual working software.
  • The product is developed in stages through the product incremental cycles known as sprints.
  • The client benefits from shippable product releases at the end of incremental cycle.
  • Frequent and consistent product increments should be delivered to the client.
  • The client, and the business, sets the priority.
  • The working process responds quickly and efficiently to the changes occurring in the market conditions, and in incorporating those changes into the product features in the least time possible.
  • Scrum teams self-organise and self-manage to determine the most efficient and quick way of delivering high priority features.

Scrum principles

Scrum functions as per certain rules or principles which are very important for its efficient working:
Individuals and interactions over Process and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan

Thursday, 10 July 2014

What to Consider Before Writing User Stories in Scrum So They Can Be More Effective and Meaningful

User stories in scrum

A user story is the main functional unit in scrum methodology. When any project is taken up for development using scrum, the specific requirements for that particular project is stated by creating a set or development requirements, which are termed as user stories in scrum. Usually the product owner creates the product backlog – the list of requirements needed to develop the project. The product backlog items are referred to as user stories by scrum professionals. Once the product requirement list is created, a small set of the requirements (user stories) are transferred to the sprint backlog during the sprint planning meeting for development purposes. The stories are explained to the team members in the first half of the sprint planning meeting. During the second half, team members distribute the stories after breaking them down into development tasks. A sprint backlog is prepared in this way. Subsequently, the team starts developing the functionalities of the user stories during the daily sprint. In scrum, the entire project is governed on the basis of the user stories.

The official scrum guide does not attempt to provide a specific definition that can describe the “structure” of a particular user story. The guide actually explains what a user story is, and what part it is supposed to play in the project. It fails to provide a standard format which can explain as to how a user story should really look like. Maybe, the reason why the guide fails to provide a structural definition is because development requirements can vary from one particular project to another.  So, it becomes difficult to standardize a specific format compatible to all types of projects.  The guide, however, states that the user story should ideally be composed of three constituent parts, or include there main aspects:

1.     A written description or a graphical representation of the entity which forms a part of the project
2.     A detailed conversation, or an explanation which additionally describes the functionality in greater details
3.     The acceptance criteria or “Done” meaning which specifies what the entity should include, how it should function, and the particular manner how it should migrate or integrate into the project

What should be considered while writing or creating user stories
While writing the user stories, certain points are important, and should be adhered to for the user stories to be effective and developmental:

·       Stakeholders should create or write the user stories
The investors and the stakeholders are funding the project for financial gains. Each project has a financial value attached to it in terms of how much the project will be worth in the market. The stakeholders know which user stories are important, and which functionalities will increase the value of the project. Therefore, they are the ideal individuals to define and create the list of requirements or the user stories. The product owner carries out the work on their behalf, and represents their interests while the project is being implemented.

·       Using simple tools to represent user stories
In the manual system, stories are written down on index or story cards specially designed for scrum. The scrum index cards are very convenient to work with, and are generally pinned on the scrum board while the sprint is underway. It is important to use a tool that is small in size, so it can be easily stored and pinned on the scrum board. It should be easily readable, simple to understand, and effective. The more simple and effective the tool is, the easier it would be for the team to understand and use it.

·       Time to be allotted to the user story
Scrum advocates time bound activities. Each activity in scrum has a certain duration associated with it, and is “time boxed”. It is important not to exceed the time limit to get the most out of scrum. Each user story is allotted a certain duration within which its development should be completed. It is essential that each user story is completed in the time allotted to it since it has a certain importance value (story points) attached to it. The project turns out to be cost effective only when the right duration of time is allotted to each user story, and each story is completed in the time allotted to it. If the time limit is not allotted, the project becomes expensive and its ROI decreases.

·       Describing and stating important non-functional aspects
Certain user stories need to be explained in further details so the team members can properly understand them. The user stories may be very important in terms of how they provide a solution for a particular end-user related requirement. They may or may not be technically complex, but it may be important for the team members to know what part the user stories are likely to play, and how much important they are as far as the overall project development is concerned. Such non-technical aspects of user stories should be explained properly so a better overview and understanding of the project related requirements is availed.  

·       Fixing the story priority
Each user story has a certain level of importance attached to it development. It is important to prioritize the user stories, so the correct time can be fixed for its development. Important user stories, or those which have more importance attached to their development, should be assigned a higher priority, and sufficient time should be allotted for completing them. On the other hand, less important stories ought to be assigned less time and priority because they do not carry much financial value with regards the functionality they offer. .

Wednesday, 12 March 2014

Reasons for Carrying Out the Product Backlog Grooming Activity

What is product backlog grooming?
The main objective of the backlog grooming session is to improve the product backlog and rearrange the user stories or the product backlog items in accordance to the new priorities determined by the stakeholders or the team members. Grooming sessions can also be held to verify the product backlog items whether they have the information necessary to develop the user stories in a more efficient manner. The scrum guide does not try to define what a backlog grooming session actually is because the “grooming” activity may vary from project to project. It is difficult to standardize the process so that it can suit all types of projects. The grooming session are generally held to:
·       Write or rewrite the product backlog items or user stories if they are not properly stated or described
·       Reschedule or reprioritize the product backlog items based upon the recent updates provided by the stakeholders
·       Segregate epics or large user stories into smaller and more manageable ones
·       Re-estimate the story points linked with the user stories
·       Update or add new acceptance criteria to the user stories

·       Analyze the product backlog for planning purposes

 Product Backlog Grooming

Different reasons why the product backlog is refined
The product backlog can be rescheduled or refined for a number of reasons depending upon the changes occurring in the market conditions or new features demanded by the end users. At times, it becomes necessary to weed out less important tasks and replace them with effective ones. The product owner may decide to reprioritize the backlog if he or she feels some of the user stories need to be developed on a priority basis. Usually, the product backlog grooming activity or product refinement is carried out because of three main reasons:

1.    Refinement carried out by the stakeholders
As the market conditions keep on changing over time and new competitive products are launched, it becomes necessary for the stakeholders to do away with some of the functionalities in the product which have become obsolete and are no longer needed. It is meaningless to spend time and efforts over features which are not likely to score for the product in the market, and which no longer have a selling value. The investors and stakeholders remain in touch with the ongoing market trends, what the end users require, and how the selling value of the product can be increased by introducing new set of features and functionalities while the product is being developed. The stakeholders may decide to “overhaul” the project by removing some of the features and functionalities, and replace them with new ones, which have added market and selling values.

2.    Informal product backlog grooming
One of the important objectives of carrying out the product grooming activity is that the team members too attend the grooming sessions, and it offers an opportunity for the product owner to explain the user stories to the development team. The product owner takes the opportunity to describe and explain the new set of product backlog items to the team members and answer questions regarding the business values of the user stories. It is a great way of understanding what the product eventually focuses to do when it is launched in the market and how it is supposed to behave when fully developed. Generally, the grooming sessions are succeeded by the sprint planning meetings, and the team is able to prepare in advance for the planning meetings in a more meaningful manner. Since the team members become more familiar with the exact functionality associated with the user stories, it becomes easy for them to segregate the user stories into development tasks during the second half of the sprint planning meeting.

3.    Periodic refinement carried out by the team members
It is important to carry out “routine maintenance work” and keep the product backlog “in shape” so it becomes easy to plan the sprints. As the sprints progress and development is carried out during the sprinting sessions, some of the tasks are completed and new functionality is developed. At time, the functionality developed can be shared with other resources to be developed, and it is important to identify such resources so duplicate or repetitive development activity can be avoided and time can be saved. The grooming session help to weed out the repetitive tasks and get the backlog back into “shape”. It also provides an opportunity to the team members to ask for clarifications and demand explanations for the stories they find it difficult to understand to the product owner.  

                "Please visit to download the Quickscrum tool"