Non-core Roles in Scrum

Non-core Roles in Scrum

The non-core roles can be described as those roles that are not mandatorily required for the Scrum project and that may not be continuously or directly involved in the Scrum process. However, knowing non-core roles is important as they can play a significant part in Scrum projects.

Non-core roles can include the following:

1. Stakeholder(s)

Stakeholder(s) is a collective term that includes customers, users, and sponsors, who frequently interface with the Product Owner, Scrum Master, and Scrum Team to provide them with inputs and to facilitate creation of the project’s product, service, or other result. Stakeholder(s) influence the project throughout the project’s development. Stakeholders may also have a role to play during Develop Epic(s), Create Prioritized Product Backlog, Conduct Release Planning, Retrospect Sprint, and other important processes in Scrum.

  • Customer

The customer is the individual or the organization that acquires the project’s product, service, or other result. For any organization, depending on the project, there can be both internal customers (i.e., within the same organization), or external customers (i.e., outside of the organization).

  • Users

Users are the individuals or the organization that directly uses the project’s product, service, or other result. Like customers, for any organization, there can be both internal and external users. Also, in some industries customers and users may be the same.

  • Sponsor

The sponsor is the individual or the organization that provides resources and support for the project. The sponsor is also the stakeholder to whom everyone is accountable in the end.

2. Vendors

Vendors include external individuals or organizations that provide products and services that are not within the core competencies of the project organization. At times, the same person or organization can play multiple stakeholder roles; for example, the sponsor and the customer may be the same.

3. Scrum Guidance Body

The Scrum Guidance Body is an optional role. It generally consists of a group of documents or a group of experts who are typically involved with defining objectives related to quality, government regulations, security, and other key organizational parameters. These objectives guide the work carried out by the Product Owner, Scrum Master, and Scrum Team. The Scrum Guidance Body also helps capture the best practices that should be used across all Scrum projects in the organization.

The Scrum Guidance Body does not make decisions related to the project. Instead it acts as a consulting or guidance structure for all the hierarchy levels in the project organization—the portfolio, program, and project. Scrum Teams have the option of asking the Scrum Guidance Body for advice as required.

Scrum : Tools and Techniques for Estimating Tasks in a Scrum Project

The Scrum Core Team uses various tools and techniques such as Task Estimation Meetings, Estimation Criteria, Planning Poker, Fist of Five, etc. to estimate the effort required to accomplish each task in the Task List. When estimating tasks, the core team create the Effort Estimated Task List which is a list of tasks associated with the Committed User Stories included in the ensuing Sprint. Now, let us analyze some of the important tools used by the Scrum Core Team to estimate tasks. Here is an introductory video on estimating tasks: http://www.scrumstudy.com/watch.asp?vid=614

The first tool or technique is the Task Estimation Meeting. This meeting enables 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. Task Estimation Meetings are sometimes also referred to as “Sprint Planning Meetings” – such meetings may also be combined with Task Planning Meetings.

Next is Estimation Criteria. The primary objective of using Estimation Criteria is to maintain relative estimation sizes and minimize the need for re-estimation. Estimation Criteria can be expressed in numerous ways, with two common examples being story points and ideal time. For example, an ideal time normally describes the number of hours a Scrum Team member works exclusively on developing the project’s deliverables, without including any time spent on other activities or work that is outside the project. Estimation Criteria make it easier for the Scrum Team to estimate effort and enable them to evaluate and address inefficiencies when necessary.

Planning Poker is another technique that can be used to estimate tasks. Planning Poker, also called Estimation Poker, is an estimation technique which uses consensus to estimate relative sizes of User Stories or the effort required to create them. In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent complexity of the problem, in terms of time or effort, as estimated by the team member. The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the team. The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it. Then, each member picks a card from the deck that represents their estimate for the User Story. If the majority or all team members select the same card then the estimate indicated by that card will be the estimate for that User Story. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached. Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of group think.

Another technique that can be used in this regard is Fist of Five. Fist of Five is a simple and fast mechanism to achieve consensus in a group and drive discussion. After initial discussion on a given proposal or a pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. The value in using this technique is not only consensus building but also driving discussion because each team member is asked to explain the reason for their ranking. They are also given the opportunity to express any issues or concerns. Once the team has discussed it, a collective decision will be made. The number of fingers used to vote indicates the level of agreement and desire for discussion:

  1. One finger: I disagree with the group’s conclusion and have major concerns.
  2. Two fingers: I disagree with the group’s conclusion and would like to discuss some minor issues.
  3. Three fingers: I am not sure and would like to go with the group’s consensus conclusion.
  4. Four fingers: I agree with the group’s conclusion and would like to discuss some minor issues.

Five fingers: I wholeheartedly agree with the group’s conclusion.

SCRUM : Definition of Quality in Scrum

SCRUM : Definition of Quality in Scrum

There are numerous ways to define quality. In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements.

The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements. Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through repetitive quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint.

Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Here is a video on how Scrum defines quality: http://www.scrumstudy.com/watch.asp?vid=524

Now, let us look at how quality is linked with scope, business value and other aspects or elements of a project. The scope of a project is the total sum of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog, and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provides the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

Importance of Business Value – Is it enough for Scrum Backlog Prioritization?

Importance of Business Value – Is it enough for Scrum Backlog Prioritization?

Delivering maximum business value in a minimum time span is ingrained in the Scrum framework. Usually, Scrum projects are expected to create business or service value which makes Scrum framework attractive for business stakeholders.

But it is not clear if Business Value can be achieved by reducing costs involved, increasing the end revenue, enhancing customer delight, minimising risk or enhancing organizational capability. Business value and its assignment is a subjective task that requires balancing a lot of information based on lot of changing priorities. Product owner uses it as an indicator to prioritize the product backlog. Product backlog prioritization includes many other variables and attributes. Therefore, prioritization based on business value should not be the only approach. A good product owner should have strong understanding of the product’s vision and a good rapport with the customer and development team. Product owner should also take calculation of risk and effort into account while prioritizing backlogs. Product Owner should be able to forecast positive business value (gained after product is delivered) and negative business value (that can bring down the revenue figures) based on risk.

Companies in fact differ in their sales processes that determine what potential value of a product feature to launch in the market and the right time when to ship the product in the market. Stakeholders and senior management in a company decide on what to be shipped next to earn value. However, Stakeholders impose their individual wishes on the development teams or the Product Owners as their priorities do not match. A common agreement between the Stakeholders is achieved in respect to the fact, that the Product Owner should be the overall in charge of defining priorities.

Business Values are estimated in the same way the developers estimate the complexity. Estimation poker helps Product Owners and Stakeholders to get together, to share information related to Business Values and come up with an agreement. It brings understanding and respect among them and team members.

The practice of estimating business value on each story faces some problems like assigning a discrete value on small features or bits of functionality and determining the cost of the feature. However, that does not mean that we should not do ROI analysis of user stories or put business value to features .During such analysis and estimation a balance should be maintained between value and the cost associated. It is best done at the level of large user stories.

Collaboration in Scrum

Collaboration in Scrum

Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. It is important to note the difference between cooperation and collaboration here. Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team. Collaboration occurs when a team works together to play off each other’s inputs to produce something greater.

collaboration in scrum

The core dimensions of collaborative work are as follows:

  • Awareness—Individuals working together need to be aware of each other’s work.
  • Articulation—Collaborating individuals must partition work into units, divide the units among team members, and then after the work is done, reintegrate it.
  • Appropriation—Adapting technology to one’s own situation; the technology may be used in a manner completely different than expected by the designers.

Collaboration ensures that the following project benefits are realized:

  1. The need for changes due to poorly clarified requirements is minimized.
  2. Risks are identified and dealt with efficiently. For example, risks to the project are identified and assessed in the Develop Epic(s), Create Deliverables, and Conduct Daily Standup processes by the Scrum Core Team members. The Scrum meeting tools such as the Daily Standup Meeting, Sprint Planning Meeting, Prioritized Product Backlog Review Meeting, and so on provide opportunities to the team to not only identify and assess risks, but also to implement risk responses to high-priority risks.
  3. True potential of the team is realized. For example, the Conduct Daily Standup process provides scope for the Scrum Team to collaborate and understand the strengths and weaknesses of its members. If a team member has missed a task deadline, the Scrum Team members align themselves collaboratively to complete the task and meet the targets agreed to for completing the Sprint.
  4. Continuous improvement is ensured through lessons learned. For example, the Scrum Team uses the Retrospect Sprint process to identify what went well and what did not go well in the previous Sprint. This provides an opportunity to the Scrum Master to work with the team to rework and improve the team for the next scheduled Sprint. This will also ensure that collaboration is even more effective in the next Sprint.

Don’t be a Scrumbut

Don’t be a Scrumbut

Do you really use Scrum, do you follow Scrum as it is or you use Scrum, but you do a few things differently?

This is a new term which has made its entry in the past few years. If you ask anyone if they have ever used scrum for their organization or project. You will hear the response, yes, we use scrum, But we don’t have Daily Stand up as every team member is not available all days. Or let’s say this sprint was 2 week and the next sprint was for 5 weeks.

Or I hear, that the development team reports its status to the Scrum Master. Or in your retrospective, you are more worried about who rather than what, went wrong.

Scrumbut means, one who uses the word “but” when answering the question “Do you do Scrum?”

You will not be a scrumbut, if you pass this 12 point Scrum test:

1. Use short iterations; fix the sprint size to two to four weeks

2. Appoint a Scrum Master who will remove impediments

3. Have an ordered sprint backlog, before the sprint which will include 100% inventory of all work: be it feature, defects and all tasks

4. make sure that the entire team is jointly accountable for the success of the project.

5. Have a Sprint Planning workshop where the team commits to sprint goals and fine-grain features and get ready to start the sprint

6. Fine-grain features are broken into tiny tasks. If any task estimates are over 4 hours, break them down further.

7. Do Daily scrum meetings: and answer the questions what did you do, what are you going to do, what may be blocking you from completing your work and what do you need from other team members

8. Do not do anything that is not estimated and is not in the sprint backlog

9. Establish the Done Criteria, publish it to the team and Meet the Done Criteria for each story and the Sprint.

10. Track Sprint Backlog by using Burn-down chart or the Burn-up chart on a daily basis

11. Keep the product owner in the loop at all times.

12. Hold Sprint Review and Sprint Retrospective at the end of each sprint and work on what you can improve rather than fault finding.

Scrumbuts are the reasons why many scrum teams cannot take the full benefits of product development using Scrum.

Why go for Scrum?

Why go for Scrum?

Scrum has become one of the most popular Agile methodologies used for software and product development. Various factors have contributed to this popularity. The methodology works very well with complex projects where requirements change often and/or the technology is new and not used before. How does Scrum do this? What supports this framework?

Scrum is rooted in values through its various principles. One of the most important principles of this Agile framework is Empirical Process Control which is based on the ideas of transparency, inspection, and adaptation. Detailed upfront planning takes a backseat as decisions made are based on observation and experimentation. Let’s examine the ideas behind Empirical Process Control.

All aspects of every Scrum process are observable by all stakeholders contributing to an open work culture. Scrum Artifacts like Project Vision Statement, Prioritized Product Backlog, and Release Planning Schedule are visible to all. Scrumboards and Burndown Charts are accessible easily to gauge the progress of the Development team. Tools like the Daily Standup Meetings make the progress and problems in the project transparent.  At the end of every Sprint, the Product Owner and Stakeholders view the Sprint deliverables developed by the Development team. All of these tools and mechanisms support Empirical Process Control through a great deal of transparency.

Inspection and adaptation occurs throughout the Development process using Scrum. Elements are inspected during the Sprints through meetings and artifacts. Feedback is collected from end users and affected parties for the improvement of the product. The deliverables are inspected at the end by the Product Owner/Stakeholders through the demonstration by the Development team. All elements inspected, made possible through a transparent mechanism, are then improved through effective adaptation. Impediments are removed on a daily basis, risks are identified as the project moves along, change requests are incorporated as deemed fit. All of these ideas come together to make Empirical Process Control a highly effective way of software/product development.

The other five principles of Scrum are Self-organization, Collaboration, Value-based Prioritization, Time-boxing, and Iterative Development. All of these principles work cohesively to bring out major benefits from Scrum. As mentioned earlier, there is a continuous stream of feedback leading to improvements. Thus, value is delivered continuously through iterative processes which are designed for people to maintain a sustainable pace. There is also early delivery of high value. This is carried out through the “Create Prioritized Product Backlog” process which makes sure that the items which possess the highest value for the customer are developed and delivered first.

Time-boxing in Scrum leads to greater levels of efficiency. Most elements which are not required are eliminated or minimized which adds to the effective functioning of the team. Members of the Development team are highly motivated through processes like Conduct Daily Standup and Retrospect Sprint. Needless to say when teams are highly motivated they perform very well. There is a lot of collaboration among the cross-functional self-organized team members which results in faster problem resolution which is ideal for complex projects.

Further, a customer-centric framework is built by the special stress laid on business value and a collaborative approach towards stakeholders. Owing to better transparency and collaboration, employees experience and enjoy elevated levels of trust in the work environment, which contributes to their productivity. A collective ownership of a project by a self-organizing Scrum team allows for improved quality results. The collaboration is conducive to the achievement of near full potential of the cross-functional team and increased velocity.

All these value-based principles of Scrum generate factors that create an innovative environment of continuous learning. With all these benefits of Scrum it becomes evident why the framework is popular in software/ product development.