How are decisions made in Scrum?

June 9, 2014
By

How are decisions made in Scrum?

In Scrum, decisions are made based on observation and experimentation rather than on detailed

upfront planning. Empirical process control relies on the three main ideas of transparency, inspection,

and adaptation.

Transparency

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy

and transparent flow of information throughout the organization and creates an open work culture. In

Scrum, transparency is depicted through the following:

• A Project Vision Statement which can be viewed by all stakeholders and the Scrum Team

• An open Prioritized Product Backlog with prioritized User Stories that can be viewed by

everyone, both within and outside the Scrum Team

• A Release Planning Schedule which may be coordinated across multiple Scrum Teams

• Clear visibility into the team’s progress through the use of a Scrumboard, Burndown Chart, and

other information radiators

• Daily Standup Meetings conducted during the Conduct Daily Standup process, in which all team

members report what they have done the previous day, what they plan to do today, and any

problems preventing them from completing their tasks in the current Sprint

• Sprint Review Meetings conducted during the Demonstrate and Validate Sprint process, in

which the Scrum Team demonstrates the potentially shippable Sprint Deliverables to the

Product Owner and Stakeholders

Inspection

Inspection in Scrum is depicted through the following:

• Use of a common Scrumboard and other information radiators which show the progress of the

Scrum Team on completing the tasks in the current Sprint

• Collection of feedback from the customer and other stakeholders during the Develop Epic(s),

Create Prioritized Product Backlog , and Conduct Release Planning processes

• Inspection and approval of the Deliverables by the Product Owner and the customer in the

Demonstrate and Validate Sprint process.

Adaptation

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and

inspection and then adapt by making improvements in the work they are doing. Some examples of

adaptation include:

• In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing

their tasks and seek help from other team members. More experienced members in the

Scrum Team also mentor those with relatively less experience in knowledge of the project or

technology.

• Risk identification is performed and iterated throughout the project. Identified risks become

inputs to several Scrum processes including Create Prioritized Product Backlog, Groom

Prioritized Product Backlog, and Demonstrate and Validate Sprint.

• Improvements can also result in Change Requests, which are discussed and approved during

the Develop Epic(s), Create Prioritized Product Backlog, and Groom Prioritized Product Backlog

processes.

• The Scrum Guidance Body interacts with Scrum Team members during the Create User Stories,

Estimate Tasks, Create Deliverables, and Groom Prioritized Product Backlog processes to offer

guidance and also provide expertise as required.

• In the Retrospect Sprint process, Agreed Actionable Improvements are determined based on the

outputs from the Demonstrate and Validate Sprint process.

• In Retrospect Project Meeting, participants document lessons learned and perform reviews

looking for opportunities to improve processes and address inefficiencies.

With other methods, like the traditional Waterfall model, considerable planning needs to be

done in advance and the customer generally does not review product components until near the

end of a phase, or the end of the entire project. This method often presents huge risks to the

project’s success because it may have more potential for significantly impacting project delivery and

customer acceptance. The customer’s interpretation and understanding of the finished product may

be very different from what was actually understood and produced by the team, and this may not

be known until very late in the project’s development.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

*


two − 1 =

Subscribe

Follow Us On

Post-Plugin Library missing