Scrum : Important Roles in a Scrum Project

It has been proved by surveys that additional certifications such as ITIL, PRINCE2, PMP and Scrum can not only help a professional (IT or non-IT) gain more knowledge regarding success in their projects, but also help an organization in which he/she works in the long run. One of the most similar facts that can be seen from these certifications is that they all emphasize the importance of roles and non-roles in their projects. In this article, the emphasis is placed on roles and non-roles of an organization. In Scrum training or Scrum certification, a lot of time is dedicated to defining and understanding roles and responsibilities for the success of every project.

The roles of Scrum fall into two categories, i.e., core and non-core roes. In Scrum, core roles are defined as the roles that are mandatorily considered necessary for production of the project, they are and should be committed to the specific project and also responsible for success in every Sprint of the project and for the entire project. Non-core roles are those roles which are not mandatory in a Scrum project. The roles may consist of members interested in the project though they might not have any formal role in the team. But they are given permission to interact with the members of team. They may or may not be responsible for the outcome of the project. But in Scrum, it has been clearly specified that these roles should also be considered.

Here is a video on the Scrum Project Roles: http://www.scrumstudy.com/watch.asp?vid=454

Core Roles are further divided into three and they are held responsible for meeting the objectives of the project. Commonly referred to as the SCRUM core team, they are known by the names: Product Owner, Scrum Master and Scrum team. But the important fact to be taken into account is that these roles have or given no authority over other roles. Let us first consider the role of Product Owner. The responsibility of maximization of business value in a project is assigned to this role. It includes articulating requirements of the customer and maintenance of justification of business about the project. In short, Product Owner can be defined best as the Voice of the Customer.

Next is the Scrum Master role. Scrum Master can be best described as the person who ensures that the environment in which the team works is as per the guidelines that are required to develop the product or service successfully. Finally, the Scrum Team is a group of members responsible for understanding the requirements of the business as specified by the Product Owner, who estimates User Stories and creating the project Deliverables.

scrum : Information Radiators or Tools in Scrum Projects

One of the main advantages of Scrum is that the whole activity is transparent for all and the information can be viewed directly from information tools such as Scrumboard, where the progress of the team can be made visible. The progress of a team can be planned accurately and tracked by the Scrumboard during each Interval of a Sprint. The Scrumboard consists of four columns for indicating the progress of the proposed tasks in a Sprint; the first one consists of the “To Do” column, i.e., for tasks in the pipeline, the second column consists of a “To Do” column for tasks that have not yet started, the third one for “In Progress” column for the tasks that are in action but not concluded and the final column stands for tasks which have been completed including the successful completing of tests. It has to be noted that in the initial stages of a Sprint, all the tasks for that phase are confined to the “To Do” column and their place changes as the project proceeds to completion.

The Scrum board is usually maintained on a white board or on paper, or as in recent times, where it is managed electronically on a Spreadsheet. Changes in the Scrumboard should be managed by the Scrum team as per the standards of time so that the information is transparent for the stakeholder and other team members to ensure that the project is on the right track as per the guidelines.

Another important tool in this regard is Impediment Log in which all the impediments affecting the project are documented. An Impediment is usually described as an obstacle, hindrance or hurdle which can decrease the productivity and performance of the Scrum team. It is mandatory that they should be identified as soon as possible, solution found in quick time and they should be removed in order for the team to contribute effectively. They can be classified into two types: Internal and External. Internal Impediments can be classified as either improper communication or reduction in performance of workforce whereas External impediments could involve various factors such as requirement of unnecessary documents or issues in software license. An organization can suffer from unwanted cost if it fails in identification or not finding an appropriate solution in dealing with this factor. The Scrum Master is responsible for recording the impediments in the Impediment Log and these issues can be discussed and sorted in Daily Standup Meetings and Sprint Review Meetings.

Sprint Burndown Chart is another key information radiator in Scrum. The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

Here is a video on the Sprint Burndown Chart: http://www.scrumstudy.com/watch.asp?vid=615.

Scrum : Lifecycle of a Scrum Project

As with other certifications such as ITIL, PRINCE2 or PMP, SCRUM can also be described as an additional way in which organizations can achieve their goal of providing the best services or products to their customers. A new service which has to be designed or modification of an existing service can be termed as projects by organizations. But these so-called projects can become restrained due to shortage of time, resources, financial cost, and various challenges which can make an organization vulnerable to improper planning, execution, management and succession of projects. Organizations have henceforth formulated different methodologies for proper project management.

Scrum has become one of the most sought-after methodologies to be implemented for success of a project. One of the advantages of Scrum is that it ensures transparency for communication where the conversation becomes easy for collective accountability and consistent progress. Every methodology will have a special feature by which the challenges related to a project can be met. The benefits of Scrum are the usage of self-empowered, well-organized and across-department teams who can divide a project into little work cycles known popularly as Sprints.

Here is a video describing the Scrum methodology: http://www.scrumstudy.com/watch.asp?vid=434

Similar to the beginning of any project, the Scrum cycle also begins via a stakeholder meeting in which the details are explained to the delegate called as “Project Vision.” A Prioritized Product Backlog is then designed and developed by the Product Owner. The Backlog consists of a list of project and business requirements according to their priorities in the formula of user stories. A Sprint is usually begun with a “Sprint Planning Meeting” and during the discussion high priority issues and stories will be included in the sprint. The time-limit of a Sprint will be between one and six weeks and will involve the Scrum team.

The highlights of the meeting will be the short, to-the-point stand-up meetings which will be conducted and the SCRUM team will discuss the daily progress of the project. When the time-limit is concluded, a Sprint review meeting is conducted and the Product Owner and concerned stakeholders will be provided updates and demonstrations regarding the Deliverables. The Product Owner has the option to accept the Deliverables provided they meet the accepted criteria or reject it if they do not meet the concerned guidelines.

The conclusion of the Sprint Cycle is the “Retrospect Sprint Meeting” in which the team suggests ways on improving the processes and their performance in moving forward into the subsequent Sprint. Organizations that have used Scrum in their projects, vouch for its many benefits, some of them, adaptability, transparency, continuous improvement, motivation, faster problem resolution, and innovative environment.

Scrum : Quality Considerations in Scrum Projects

“Quality is baked in,” we have often heard this statement. But to actually understand what it means in the Agile context, we need to have a QA mind-set. Let’s take an example to understand this. As part of a proposed acquisition, my boss asks me to perform some final due diligence on the development team and its product. We’d already established that the company’s recently launched product is doing well in the market, but I have to make sure we are not about to buy more trouble than benefit. So I spend my time with the development team.

Here is a video on quality considerations in Scrum project: http://www.scrumstudy.com/watch.asp?vid=585

I am looking for problems that might arise from having rushed the product into release. I wonder, “Was the code clean? Were there modules that could only be worked on by one developer? Were there hundreds or thousands of defects waiting to be discovered?” And when I ask about the team’s approach to testing, “Quality is baked in” is the answer I get. Because this rather unusual colloquialism could mean just about anything, I press further. What I find is that this is the company founder’s shorthand for expressing one of the quality principles: Bring quality in your development phase itself, rather than waiting for the testing phase. The idea of building quality into their products is at the heart of how agile teams work. Agile teams work in short iterations in part to ensure that the application remains at a known state of quality. Agile teams work in a cross-functional manner, with everyone working side-by-side in every iteration to improve the quality of the product thorough techniques like automation, refactoring, pair programming, integration etc.

Here a dedicated tester is involved throughout the timeline, continuously testing recently developed codes, and integrating them with the existing codes to conduct a functionality test as well. Smoke testing is also encouraged to improve the quality of the demo to be shown to the clients. Learning how to do these things is difficult, and especially so for testers, whose role changes dramatically in an Agile environment. It is important to look at the questions a tester will have in his/her mind while embarking on an agile project, such as:

·         What are my roles and responsibilities?

·         How do I work more closely with programmers?

·         How much do we automate, and how do we start automating?

Once these questions are answered, a tester will be able to perform his/her role in an Agile environment in a much better way.

Scrum : Managing Changes through Prioritized Product Backlog

Managing Changes through Prioritized Product Backlog Grooming A typical Prioritized Product Backlog will contain all User Stories, their time estimates which also includes any revised estimates, and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is grooming the Prioritized Product Backlog to ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next two to three Sprints are refined into suitable User Stories. It is recommended that the Product Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog grooming. The Product Owner is responsible for adding and revising Prioritized Product Backlog Items in response to any changes and is responsible for providing more detailed User Stories that will be used for the next Sprint.

Here is a video on managing change using Prioritized Product Backlog:  http://www.scrumstudy.com/watch.asp?vid=590

Grooming helps ensure that refining of requirements and their User Stories is done well in advance of the Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.

A Product Backlog Review Meeting (also referred to as a Prioritized Product Backlog Grooming Session) is a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth. It is important to note that any item in the Prioritized Product Backlog is always open for re-estimation until the Sprint Backlog is finalized in the Create Sprint Backlog process. After that, changes can continue to be made until immediately prior to the Sprint Planning Meeting, if required.

Scrum : Planning and Estimation in Scrum

Planning and estimating tasks in Scrum involves creation of User Stories, approval and estimation of User Stories, creation and estimation of tasks, and creation of Sprint Backlog. Creation of User Stories involves writing of User Stories and their related User Story Acceptance Criteria. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. The Product Owner, based on his or her interaction with the stakeholders, business knowledge and expertise, and inputs from the team, develops User Stories that will form the initial Prioritized Product Backlog for the project. The Prioritized Product Backlog represents the total sum of what must be completed for the project. The objective of this exercise is to create elaborated and refined User Stories that can be approved, estimated, and committed to by the Scrum Team. At times, the Product Owner may bring a Business Analyst to assist with writing User Stories. User Story Writing Workshops may be held for creating the User Stories.

Although the Product Owner has the primary responsibility for writing User Stories and often carries out this exercise on his or her own, a User Story Writing Workshop can be held if desired. Approval for User Stories of a Sprint is provided by the Product Owner. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story. Finally, the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.

The approved, estimated, and committed User Stories are broken down into specific tasks and compiled into a Task List. Often, a Task Planning Meeting is held for this purpose. In Task Planning Meetings, the Scrum Team gets together to plan the work to be done in the Sprint. The team reviews the committed User Stories at the top of the Prioritized Product Backlog. The Product Owner is present during this meeting in case clarification is required related to User Stories in the Prioritized Product Backlog and to help the team make design decisions. To help ensure that the group stays on topic, this meeting should be Time-boxed, with the standard length limited to two hours per week of Sprint duration. This assists in preventing the tendency to stray into discussions that should actually occur in other meetings, like the Release Planning or Sprint Review Meetings. By the end of the meeting, the entire Scrum Team will have fully committed to deliver a subset of User Stories from the Prioritized Product Backlog in the Sprint.

Here is a video on planning and estimation in Scrum: http://www.scrumstudy.com/watch.asp?vid=611

Then the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. Task Estimation Meetings enable the Scrum Team to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. In Task Estimation Meetings, the Scrum Team members use the Task List to estimate the duration and effort for the User Stories to be completed in the Sprint. One of the key benefits of this technique is that it enables the team to have a shared perspective of the User Stories and requirements so that they can reliably estimate the effort required. The information developed in the Task Estimation Meetings is included in the Effort Estimated Task List and it is used to determine the velocity for the Sprint. In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation. The result of Task Estimation Meeting is, often, an Effort Estimated Task List.

And finally, the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint. During Sprint Planning Meetings, the User Stories, which are approved, estimated, and committed during the Approve, Estimate, and Commit User Stories process, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The Scrum Team also creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during the Sprint Planning Meetings.

Scrum : Value-driven Delivery in Scrum

Business justification in Scrum is based on the concept of Value-driven Delivery. One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, Scrum attempts to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders.

Scrum’s adaptability allows the project’s objectives and processes to change if its business justification changes. It is important to note that although the Product Owner is primarily responsible for business justification, other team members contribute significantly.

A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people, and organizational capabilities. Usually, the results generated by projects are expected to create some form of business or service value.

Since value is a primary reason for any organization to move forward with a project, Value-driven Delivery must be the main focus. Delivering value is ingrained in the Scrum framework. Scrum facilitates delivery of value very early on in the project and continues to do so throughout the project lifecycle.

Here is a video on value-driven delivery: http://www.scrumstudy.com/watch.asp?vid=520

One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested stakeholders.

In order to provide Value-driven Delivery, it is important to:

1.       Understand what adds value to customers and users and to prioritize the high value requirements on the top of the Prioritized Product Backlog.

2.       Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with project stakeholders showing them product increments at the end of each Sprint, enabling effective management of changes.

3.       Create Deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project.

The concept of Value-driven Delivery in Scrum makes Scrum framework very attractive for business stakeholders and senior management. This concept is very different when compared with traditional project management models where:

1.       Requirements are not prioritized by business value.

2.       Changing requirements after project initiation is difficult and can only be done through a time consuming change management process.

3.       Value is realized only at the end of the project when the final product or service is delivered.

Here is a video on Scrum vs. traditional project management: http://www.scrumstudy.com/watch.asp?vid=523

The following diagram contrasts Value-driven Delivery in Scrum versus Traditional projects.

SCRUM : What are Done Criteria?

Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

·         Reviewed by other team members

·         Completed unit testing of the User Story

·         Completion of quality assurance tests

·         Completion of all documentation related to the User Story

·         All issues are fixed

·         Successful demonstration to stakeholders and/or business representatives

The key difference between Done Criteria and Acceptance Criteria is that while Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. But as with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done.

Here is a video on Done Criteria: http://www.scrumstudy.com/watch.asp?vid=594

The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms. The definition of Done is typically determined and documented by the Scrum Guidance Body.

Example of Done Criteria: Done Criteria for a project of designing the new variants of a popular sports car at LRA Ltd are:

·         The design is approved by the Technical Excellence division.

·         The prototype passes all wind tunnel tests mandated by the Aerodynamics division.

·         The design is cleared for production by the Intellectual Property division.

·         The design's safety expectations are corroborated by the Safety Division's Design Safety report.

·         The Cost Estimation report for the design is approved by the Finance division.

The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases. The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

Toward the end of any iteration, the respective business unit and stakeholders participate in a Sprint Review Meeting in which the product increment is demonstrated to the Product Owner, sponsor, customer, and users. While feedback from all the stakeholders is gathered, only the Product Owner has the power to accept or reject a particular User Story as Done, according to the agreed upon Acceptance Criteria and Done Critieria. Thus, Acceptance Criteria and Done Criteria play a vital role in maintaining quality and need to be clearly understood by the team.