Showing posts with label User Stories or Product Backlog Items. Show all posts
Showing posts with label User Stories or Product Backlog Items. Show all posts

Monday, 9 June 2014

A Brief Overview about What Is Agile Scrum Framework and How It Can Help You in Developing Successful Projects

Scrum is a specialized type of project development framework. It is very popular owning to its fast and reliable product development cycle. It can be used for developing products, especially software based products, for which it is very extensively used nowadays. Many Fortune 500 companies currently use the scrum development methodology across the world owing to its popularity and effectiveness in delivering high quality products within the stipulated development time. The unique aspect about scrum framework is that it has an ability to “inspect” what is happening “in” and “around” a project in which it is implemented, and it can take corrective actions based upon the findings received as inputs from the process flow. The framework supports several activities known as “events” which can help to identify if anything wrong is happening with the project. When a malfunction or an erroneous activity is detected, the framework can take corrective steps to ensure that the “wrong” thing is corrected and rectified in a correct manner. The scrum framework is so structured that it can “self-detect” and “self-correct” itself through its events and specialized working.   

Typically, scrum is a development process in which teams collaborate and work together while creating the product. In scrum, development occurs in small stages known as “sprints.” Each small burst of development activity, or sprint, generally lasts from two weeks up to one month. At the end of each sprint, a special event known as the “sprint review” is held to find out how much development work has been carried out by the team, and how much of it is acceptable from the quality control point of view. Completed work is consolidated and accepted as “Done.” The unique aspect about scrum is that development is carried out in bits and pieces, rather than “as a whole” and “all together.” Each piece or developmental unit is developed individually and tested for flaws. These pieces are subsequently integrated to form the complete product. Rather than controlling the project as a whole, scrum ventures to control the development of individual pieces or product functionality. The developmental units, or “pieces” are referred to as “user stories” in scrum. Once all the user stories are developed and integrated, a total, comprehensive, and “shippable” product is automatically developed. This product is tested at a micro level with regards its functioning and reliability. This is one of the major reasons why many development companies and organizations prefer to use scrum framework in their production processes.

There are many reasons why people choose scrum for their project development activity.

Reduces technical debt and eliminates regression
At any given instance of time, the team develops a small portion, or a thin slice, of the actual product. This portion is further divided into even smaller developable units that are individually developed by the team members. Once a particular “unit” is completely developed, it is tested for its completeness and usability. It provides an opportunity for the team to test individual product components at a micro level. Tackling problems at a root level leads to zero regression and highly reduced technical debt in the future. This is how scrum controls technical debt related problems before and after product deployment.

Maintain the business value of the project at all times
After a small portion of the product is developed and tested for its reliability, it is demonstrated or showcased to the project owners and stakeholder – people who actually own the project. Their feedback is availed regarding the functionality which has been developed by the scrum team. Once they Okay the development, the portion is accepted as “Done.” If the owners are not satisfied, the development is transferred to a master list from which it can be taken up again for development purposes. Thus, only useful and effective developmental activity is carried out in the framework. The system is so structured that it can reject substandard work. Moreover, each developmental unit can be correlated with its “worth” in the market i.e. when a particular functionality is developed by the team how much it will be worth in the market when integrated in the actual product. This ensures that only meaningful development having a certain financial significance is “churned” out by implementing the scrum framework. Each product unit developed has a certain business value attached to it. This ascertains that the business value of the entire project is maintained at all times.

Collaborative features which can streamline productivity and increase it
One of the biggest advantage of scrum framework is that it solicits feedback from the team members and the project owners at all times. Each user story, or the development unit, is precisely stated in a master list known as a “product backlog.” This master list contains each and every “item,” or a developmental unit needed to develop the product in totality. Each item in the list is minutely defined. The specifications of the functionality to be developed, its description, explanation, and what benchmarks it needs to satisfy to be accepted as “Done” are clearly stated in it. This makes development much easier for the team members since the criteria is clearly laid down and the team knows exactly what functionality to develop, in what manner, and what kind of outputs are expected after developing the product item. The feedback system further helps the team to collaborate and discuss the technical aspects regarding the development activity. This helps to streamline the production process. The team members can help each other during the product development phase. All senior as well as junior team members support the collaborative nature. When the team faces any problems or impediments, a project leader known as a “product owner” tries to provide a solution for the problem – if necessary by interacting with the stakeholders and other technically sound individuals. The collaboration process helps the team to function in a highly productive manner.

Adapting to changing market conditions and developing successful projects
A major advantage with scrum is that if follows the “inspect” and “adapt” principles. The framework possesses inherent features which facilitates inspection and retrospection. The development of a product can take a certain time. If the product definition is complex or complicated, it may take a longer time – even months – to develop the product in totality. Many a times while the product is being developed, the market conditions may change over time and render some of the functionality associated with the product as redundant. As a result, a product when launched in the market after months of development may lose its business value and find it difficult to compete with other similar products, because other products may have gained a “stronghold” and strengthened their position owing to their prior release. Companies more than often suffer substantial financial losses when this happens. Scrum helps to avoid this. The stakeholders are very closely associated with the project during its developmental phase. They have the opportunity to decide which of the product functionalities carry high business values, and which functionalities can help the product to succeed financially in the market. During the product development cycle, the stakeholders can introduce new functionality, remove existing functionality, and even suggest changes in existing functionality so that the entire project is able to maintain its business value at all times – during its inception, development, and the subsequent release. Projects developed using scrum framework are profitable and help to earn higher ROI for the stakeholders.

These are only a couple of reasons why organisations across the world opt for scrum framework. The are many other factors which entice “C” level executives and mega corporate to choose scrum as their development framework, however, it would take a much more detailed discussion and a personal coaching to truly understand the vastness and depth offered by scrum. The framework is so agile that it can adapt to almost every type of project, however large and complicated it may be, and still deliver it successfully and nicely “wrapped up” for its final deployment. It is worth knowing something more about scrum to avail a better picture about how it functions.

The scrum process starts with an activity known as a “Release Planning.” When a project is planned, or decided, the stakeholders appoint a person to execute and look after the entire project. The person is known as a “Product Owner.” The person represents the stakeholders and their interest in the project. The product owner (or the “PO” in short) starts planning about what needs to be done to execute the project in a systematic and planned manner. He or she starts preparing the documentation which includes various aspects concerning the project, such as the feasibility aspect, market dynamics, product specifications, etc. The report is presented to the stakeholders, which helps them to decide further as to what they actually need and desire out of the project. The report helps the stakeholders to understand the reality about how the product proposed by them is likely to perform in the market based upon what they have envisioned. This process is generally known as a “release planning.” The PO then proceeds with the project based on their feedback and suggestions. The PO starts preparing a master list known as a “product backlog” in scrum. The list contains individual items, known as “product backlog items” or “user stories,” which are required to develop the entire product. So looking at it conversely, the entire project is bifurcated into smaller individually developable parts known as user stories, which actually form the product backlog. The PO carefully writes down these stories. He or she can also invite and take help from the team members while drafting the stories. The stories include specifications about the functionality to be developed by the team. Once the backlog is created, the PO analyses which of the stories are most important from the functionality point of view, and which of them carry high business values. Important stories are located in the top of the list so they can be developed first. Generally, the product backlog is processed from top to bottom, so important stories can be developed first.

The sprint planning meeting
The actual development activity starts with a scrum event known as “Sprint Planning.” A meeting is conducted to support this event. The sprint planning meeting is actually held in two parts. During the first part of the meeting, the PO takes some of the important user stories from the top of the product backlog and transfers them to a temporary list known as a “Sprint Backlog.” This list is important to the team members since it contains the product items which are to be developed in the subsequent days. During the meeting, the PO explains what needs to be developed, in exactly what manner, and what conditions need to be satisfied to have the user stories accepted as successfully completed. The conditions are known as “Acceptance Criteria.” The team avails an opportunity to ask questions and seek clarifications regarding the subtle development points which are not clear. In the second half of the meeting, the team analyses the sprint backlog which contains items to be developed in the coming days. The members split up the stories into small developable sub-units known as “tasks.” Once the tasks are distributed amongst the team members, the actual development process starts.     

The daily scrum or “stand up” meetings
In scrum, the actual product development is carried out in short bursts of activities known as sprints. A sprint generally lasts for two weeks up to a maximum of one month. The PO and the team collectively decide the actual duration of the sprint keeping in mind various factors such as the level of complexity, size of the projects, the product release date, etc. Once a sprint duration is decided, it is “fixed” and cannot be changed later on. Each day, before the developers start with their day, a brief meeting is held to initiate the daily sprint activity. This meeting is called the “stand up” meeting or the “daily scrum.” The reason why the word “scrum” is used to describe the meeting is that scrum team members huddle together just as rugby players do on the field when they start with their “rugger” scrum. The purpose of holding the meeting is to make the team accountable for the work it has carried out the day before, and discuss what work is to be carried out on that particular day. The daily scrum meetings provide an opportunity for the team to briefly discuss and provide feedback regarding how many tasks have been completed by them. If any team member faces an issue or a problem, it is discussed in the meeting and a solution is availed to resolve the impediment. The meeting is very brief and time boxed. It should not extend for more than 15 minutes. The meeting is held on each day of the sprint to “start the day.”

The sprint review meeting
The development work is carried out by the team in the daily sprints. At the end of two weeks (sprint duration), when the sprint is completed and user stories have been developed by the team, the PO checks the development and verifies whether the stories have been developed properly, and whether the acceptance criteria is satisfied correctly. In scrum, it is very important to develop “shippable” functionality i.e. the tasks developed by the team should be bug free, documented, tested, and acceptable by the stakeholders. Many cross-functional scrum teams employ testers and QC personnel whose sole task is to check whether the user stories developed by the team fulfil the acceptance criteria. If this is not possible, the PO evaluates the tasks and verifies whether they are acceptable. This process is carried out in a scrum event known as the sprint review meeting. It is held just after a sprint is completed. The main purpose of this meeting is to verify the development work, and if some of the tasks do not fulfil the acceptance criteria, they are “rejected” and transferred back to the product backlog from where the user stories can be taken up again for development. Thus, regression is “checked” and controlled through the scrum process.

The sprint retrospective meeting
The scrum process invites feedback from the stakeholders. People who own the project get a chance to check the productivity and provide feedback while the product is being developed. In scrum, the development and productivity of the team is directly and indirectly controlled by the feedback received from the stakeholders, end users, and the technical teams. If productivity is carried out by the team in a proper and acceptable manner, the user stories and tasks developed will have a certain business value attached with the functionality linked with the tasks. A scrum event known as the “sprint retrospective” provides an opportunity for the stakeholders to ascertain the work carried out by the team. The sprint retrospective is held immediately after the sprint review meeting. The main difference between the review and the retrospective is that in the review the PO verifies the tasks and checks for acceptance criteria, while in the retrospective the stakeholders check the user stories and tasks for the business value availed in the ongoing project. While the PO is primarily concerned with the technical aspects and represents the stakeholders’ interests, in the retrospective the stakeholders see for themselves how important the user stories are from the business point of view. The retrospective also offers an opportunity to educate the team and offer valuable suggestions to enhance the project vision and make certain aspects clear to the development team as to what the team should ideally focus upon.     

Scrum Roles

Product Owner
He or she is the main person who executes the scrum project. The person is primarily responsible for the success or failure of the scrum project, and, in addition, represents the stakeholders’ interests while scrum framework is being implemented in the project. There are many responsibilities of the product owner, and it would take a lengthy discussion to explain all of them.

Just as a supervisor overseas the production process in a manufacturing unit, similarly a scrum master overseas that scrum framework is properly implemented at all times while the project is underway. The scrum master does not actively participates in the development work carried out by the team, but rather “keeps an eye” on how things are going on and whether the team faces any impediments while work is underway. The role of a scrum master is a passive one, but important. The PO generally does not have enough time to oversee the entire project operation since he or she is actively busy with the “macro” aspects concerning the project. The scrum master, on the other hand, concentrates on the “micro” aspects of the project and remains very close to the team, and helps them directly and indirectly by removing the obstacles whenever the team faces them in any way or manner.   

Development Team
It is the main “functional” unit of the scrum team. The product is actually developed by the development team in scrum. Ideally, the development team is cross-functional i.e. each team member possesses multiple and varied technical expertise. The team members collaborate and share ideas while working. 

Scrum Artefacts Or Objects

In scrum, the entire product is broken down into smaller, individually developable units known as user stories. User stories, also known as product backlog items or PBIs, are developed by the team during the daily sprints depending upon their importance and business values. They form the base of the entire product. Individual user stories are later integrated to form the complete product. Typically, user stories include a title description, an explanation describing the functionality to be developed in the story, some important points that clarify the development activity, and the acceptance criteria. User stories also include a numeric value which indicates how important the particular story is from the business value point of view. This value is the “story point.”

Product Backlog
It is the master list which includes the product backlog items, or the individual product components, which constitute the actual product developed in the scrum project. Periodically, the product backlog is checked and verified for any missing parameters in the user stories (whether any of the product backlog item is inappropriately described or lacks proper acceptance criteria) and the business value associated with the user stories. With time, the business values of the user stories change with changing market conditions. The stakeholders provide feedback regarding the changes in the business values of the user stories, and the product owner updates the user stories with the new business value as provided by the stakeholders. This process of updating the product backlog is known as “backlog grooming” or “backlog refinement” in scrum.

Sprint Backlog
During the daily sprint, the user stories prevailing in the entire product backlog are not taken up for development. Rather a small “chunk” or portion of the product backlog is taken up for development during the daily sprints. This small portion of the product backlog is temporarily stored in a list known as the sprint backlog. The PO creates the sprint backlog during the sprint planning meeting. 

Burn down Chart
Each user story in scrum is associated with a certain business value by using story points (a numeric value indicating the importance and the business value of the user story). The correlation of the user stories with story points is important in scrum since it becomes possible to find the “rate” at which the development team is “performing.” It becomes easy to create an estimate and determine the “speed” at which the team is currently developing the user stories. This estimation can be plotted in a chart, or a graph, known as a “burn down chart” in scrum. 

 The QuickScrum project management tool developed by Bharti Softtech is a powerful, easy to use, and versatile web based scrum tool application centred upon Scrum framework. The tool helps to incorporate scrum methodology into project development, and offers a dynamic scrum management environment. It includes powerful features such as easy to use drag-and-drop features, dynamic update of each product backlog item, its status, breakdown of backlog items into individual tasks, preview of backlog items created in earlier sprints, and much more. It is ideally recommended for organisations, project managers, and scrum teams desiring to implement scrum framework in their projects. The tool helps to save time, reduce operational overheads, and increase the development team’s productivity, which can lead to higher profits and increased ROIs.Source:-

     Please visit for additional details.