Learn How to Conduct an Effective Backlog Grooming Session

A typical Prioritized Product Backlog will contain all User Stories, their time estimates (including 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.

Product Backlog Review Meeting

Also referred to as a Prioritized Product Backlog Grooming Session, the Product Backlog Review Meeting is basically 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.

Backlog Grooming Session

The Product Owner takes the lead in a Product Backlog Review Meeting which is conducted during the Groom Prioritized Product Backlog process. It is important that the Product Owner sets the objectives and ideally develop an agenda before the Product Backlog Review Meeting begins. Without these, the session will be unstructured and may prove unproductive. It is also important to limit the number of stakeholders participating in the meeting. Having too many participants tends to decrease the overall efficiency of the meeting. The Product Owner should invite only those stakeholders whose feedback is required for the grooming session. All Scrum Team members should be included because their input is valuable to the work being done and any issues encountered. If the grooming session results in any reprioritization of or change in the Prioritized Product Backlog, it is important that the team is in agreement with those changes.

Backlog Grooming Techniques

  • Develop Epic(s)
  • Create Prioritized Product Backlog
  • Conduct Release Planning
  • Create User Stories
  • Approve, Estimate, and Commit User Stories
  • Create Tasks
  • Estimate Tasks

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-analysed 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.

 

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Advertisements

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 Standupprocesses 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.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Scrum Project Roles

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. There are three central roles in Scrum that are eventually responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others.

SCRUM Project Roles1.    Product Owner

The Product Owner is the person responsible for maximizing business value for the project. He/she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.

Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

2.    Scrum Master

The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the product’s development successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.

Note that the Scrum Master role is very different from the role played by the Project Manager in a traditional Waterfall model of project management, in which the Project Manager works as a manager or leader for the project. The Scrum Master only works as a facilitator and he/she is at the same hierarchical level as anyone else in the Scrum Team—any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or for a Sprint.

Corresponding to a Scrum Master role in a project, there could be a Program Scrum Master for a program or a Portfolio Scrum Master for a portfolio.

3.    Scrum Team

The Scrum Team is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables.

A Guide to the Scrum Body of Knowledge (SBOKTM) suggests the following roles guide for the three core roles:

  1. Product Owner—It is imperative for Product Owners to read the entire chapter 3 of the guide to SBOK.
  2. Scrum Master—The Scrum Master should also be familiar with the entire chapter 3 with primary focus on sections 3.5, 3.6, 3.7, 3.8, and 3.9 of the guide to SBOK.
  3. Scrum Team— The Scrum Team should mainly focus on sections 3.6, 3.7, and 3.8 of the guide to SBOK.

Ancillary roles are other stakeholders who are involved in the scrum project, but who are not committed. Normally, ancillary roles comprise of customers, management and members of the executive team who are active participants and they collectively work towards the objectives of consulting, progress reporting and feedback collection to better work toward providing the highest value conceivable.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Who is a Product Owner?

Before we read about how to be an effective product owner, let us first understand who a product owner is and what he/she does.  A product owner is not a separate title but is a role that can be performed by a business analyst or even a representative of an end user.

A product owner is a stakeholder who acts as an interface between the business representatives and the project team. A product owner understands the business requirements and communicates it to the team for development on behalf of the customer. A product owner is responsible for creating Prioritized Product Backlog, attending daily standup meetings, and steering the development process successfully to meet the customer’s requirements. The product owner communicates the progress of the team to the sponsor and key stakeholders. He or she also continuously refines product requirements. It is also important that a product owner has  good business sense which is important while prioritizing user stories based on cost and functionality.

A product owner must be actively involved-

The test of an effective product owner is how well he/she balances the expectations of business representatives and capability of the team to deliver. There are several ways a product owner can be more effective. A common mistake product owners make is not committing enough time to understand the requirements of the Scrum Team. Product owners should be as hands-on as possible and schedule sufficient time to holding estimation workshops, planning sprints, and providing feedback for the team.

An empowered product owner nurtures an empowered team-

Customers most often expect more value to be delivered than what the team  is capable of delivering or might suggest several changes that can slowdown the speed of the development team. A product owner supports his team by managing customer’s expectations so that workflow is not affected due to unreasonable expectations. A product owner allows the team to estimate the effort required to complete the product backlog items identified for a particular sprint. At the same time, a product owner motivates the team to deliver the product backlog items committed fora sprint on time.

Technical knowledge is essential-

It is also important that product owners have some technical knowledge, though he/she does not necessarily have to be a developer themselves. Since, they will be interacting with the team on a regular basis, having a technical background can serve well while resolving issues. Technical knowledge can also help a product owner bridge the gap between technical and business aspects of a project while liaising with developers and business representatives.

 

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

What is Agile methodology?

The term “agile” generally refers to being able to move or respond quickly and easily; being nimble. In any kind of management discipline, agile as a quality should therefore be a good thing to aim for. Agile project management specifically, involves being adaptive during the creation of a product, service, or other result.

A number of Agile methodologies originated and gained traction in the 1990’s and the early 2000’s. Here are the various popular Agile methods being used.

Lean Kanban: Lean concept optimizes an organization’s system to produce valuable results based on its resources, needs, and alternatives while reducing waste. Kanban literally means a “signboard” or “billboard” and it espouses the use of visual aids to assist and track production.

Extreme Programming (XP): Originated in Chrysler Corporation, gained traction in the 1990′s. XP makes it possible to keep the cost of changing software from rising radically with time. The key attributes of XP include incremental development, flexible scheduling, automated test codes, verbal communication, ever-evolving design, close collaboration, and tying in the long- and short-term drives of all those involved.

Crystal Methods: Introduced by Alistair Cockburn in the early 1990s, Crystal methods have four roles—executive sponsor, lead designer, developers, and experienced users. Crystal Methods recommend various strategies and techniques to achieve agility.

Dynamic Systems Development Methods (DSMD): This framework was initially published in 1995 and is administered by the DSDM Consortium. DSDM sets quality and effort in terms of cost and time at the outset and adjusts the project deliverables to meet set criteria by prioritizing the deliverables into “Must have,” “Should have,” “Could have,” and “Won’t have” categories

Feature Driven Development (FDD): Introduced by Jeff De Luca in 1997 and operates on the principle of completing a project by breaking it down into small, client-valued functions that can be delivered in less than two weeks’ time. FDD has two core principles—software development is a human activity and software development is a client-valued functionality.

Test Driven Development (TDD): Also known as Test-First Development, and was introduced by Kent Beck, one of the creators of Extreme Programming (XP). It is a software development method that involves writing automated test code first and developing the least amount of code necessary to pass that test later.

Adaptive Software Development (ASD): This method grew out of the rapid application development work by Jim Highsmith and Sam Bayer. The highlights of ASD are constant adaptation of processes to the work at hand, provision of solutions to problems surfacing in large projects, and iterative, incremental development with continuous prototyping.

Agile Unified Process (AUP): Evolved from IBM’s Rational Unified Process and developed by Scott Ambler, AUP combines industry-tried-and-tested Agile techniques such as Test Driven Development (TDD), Agile Modeling, agile change management, and database refactoring, to deliver a working product of the best quality.

Domain-Driven Design (DDD): This approach was meant for handling complex designs with implementation linked to an evolving model. It was conceptualized by Eric Evans in 2004 and revolves around the design of a core domain.

All these methods of Agile differ from each other in a variety of aspects but their commonality stems from their adherence to The Agile Manifesto.

 

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Scrum Project Roles

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. There are three central roles in Scrum that are eventually responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others.

SCRUM Project Roles1.    Product Owner

The Product Owner is the person responsible for maximizing business value for the project. He/she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer.

Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

2.    Scrum Master

The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to completing the product’s development successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.

Note that the Scrum Master role is very different from the role played by the Project Manager in a traditional Waterfall model of project management, in which the Project Manager works as a manager or leader for the project. The Scrum Master only works as a facilitator and he/she is at the same hierarchical level as anyone else in the Scrum Team—any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or for a Sprint.

Corresponding to a Scrum Master role in a project, there could be a Program Scrum Master for a program or a Portfolio Scrum Master for a portfolio.

3.    Scrum Team

The Scrum Team is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables.

A Guide to the Scrum Body of Knowledge (SBOKTM) suggests the following roles guide for the three core roles:

  1. Product Owner—It is imperative for Product Owners to read the entire chapter 3 of the guide to SBOK.
  2. Scrum Master—The Scrum Master should also be familiar with the entire chapter 3 with primary focus on sections 3.5, 3.6, 3.7, 3.8, and 3.9 of the guide to SBOK.
  3. Scrum Team— The Scrum Team should mainly focus on sections 3.6, 3.7, and 3.8 of the guide to SBOK.

Ancillary roles are other stakeholders who are involved in the scrum project, but who are not committed. Normally, ancillary roles comprise of customers, management and members of the executive team who are active participants and they collectively work towards the objectives of consulting, progress reporting and feedback collection to better work toward providing the highest value conceivable.

 

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Daily Scrum Update Using Scrumboard

The Daily Scrum is one of the most important aspects of the Scrum framework. Scrum’s transparency comes from openly viewable information tools such as the Scrumboard, which shows the progress of the team. The team uses a Scrumboard to plan and track progress during each Sprint.

The Scrumboard usually contains four to five columns to indicate the progress of the estimated tasks for the Sprint:

  1. A ‘Stories’ column for the list of tasks (optional, usually a part of the Prioritized Product Backlog)
  2. A ‘To Do’ column for tasks not yet started
  3. An ‘In Progress’ column for the tasks started but not yet completed
  4. A ‘Testing’ column for tasks completed but in the process of being tested, and
  5. A ‘Done’ column for the tasks that have been completed and successfully tested.

At the beginning of a Sprint, all tasks for that Sprint are placed in the ‘To Do’ column and are subsequently moved forward according to their progress.

The Scrumboard should preferably be maintained manually on paper or a white board, but can also be maintained electronically in a spreadsheet.

The Scrum Team should change or add to the Scrumboard as required so that the board provides visual information and control about the work going on as agreed and committed by the team. Updating or referring to the Scrumboard during the Daily Scrum keeps the team focused on the tasks that remain and their priorities.

For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog