How to ensure your team does not have too much or too little to do?

June 9, 2014
By

How to ensure your team does not have too much or too little to do?

Scrum treats time as one of the most important constraints in managing a project. To address the

constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain

amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members

do not take up too much or too little work for a particular period of time and do not expend their time

and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process

• Less overheads

• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup

process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to

avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing

can lead to de-motivation of the team and may have the consequence of creating an apprehensive

environment, so it should be used appropriately.

Scrum Time-Boxes

• Sprint—A Sprint is a Time-boxed iteration of one to six weeks in duration, during which the

Scrum Master guides, facilitates, and shields the Scrum Team from both internal and external

impediments during the Create Deliverables process.

• This aids in avoiding vision creep that could affect the Sprint goal. During this time, the team

works to convert the requirements in the Prioritized Product Backlog into shippable product

functionalities. To get maximum benefits from a Scrum project, it is always recommended to

keep the Sprint Time-boxed to 4 weeks, unless there are projects with very stable requirements,

where Sprints can extend up to 6 weeks.

• Daily Standup Meeting—The Daily Standup Meeting is a short daily meeting, Time-boxed to 15

minutes. The team members get together to report the progress of the project by answering the

following three questions:

1. What did I complete yesterday?

2. What will I complete today?

3. Am I facing any impediments?

This meeting is carried out by the team as part of the Conduct Daily Standup process.

• Sprint Planning Meeting—This meeting is conducted at the beginning of a Sprint as part of

Create Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint. The Sprint

Planning Meeting is divided into two parts:

1. Objective Definition—During the first half of the meeting, the Product Owner explains

the highest priority User Stories or requirements in the Prioritized Product Backlog to

the Scrum Team. The Scrum Team in collaboration with the Product Owner then defines

the Sprint goal.

2. Task Estimation—During the second half of the meeting, the Scrum Team decides “how”

to complete the selected Prioritized Product Backlog Items to fulfill the Sprint goal.

• Sprint Review Meeting—The Sprint Review Meeting is Time-boxed to four hours for a one-
month Sprint. During the Sprint Review Meeting that is conducted in the Demonstrate and

Validate Sprint process, the Scrum Team presents the deliverables of the current Sprint to the

Product Owner. The Product Owner reviews the product (or product increment) against the

agreed Acceptance Criteria and either accepts or rejects the completed User Stories.

• Retrospect Sprint Meeting—The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-
month Sprint and conducted as part of the Retrospect Sprint process. During this meeting, the

Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes

followed, tools employed, collaboration and communication mechanisms, and other aspects

relevant to the project. The team discusses what went well during the previous Sprint and what

did not go well, the goal being to learn and make improvements in the Sprints to follow. Some

improvement opportunities or best practices from this meeting could also be updated as part of

the Scrum Guidance Body documents.

Share

Leave a Reply

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

*


two + 7 =

Subscribe

Follow Us On

Post-Plugin Library missing