Return to Answer

Clarify team composition; fix quote.

Source Link

edited Sep 10, 2014 at 16:24

50.7k
7
60
181

What's Wrong with Your Team's Processes

When the deadline is tight and when there isare not enough QA people, andthe Product Owner asks developers to join in with QA to meet the deadline.

Your process problems are legion. Let me count at least some of the ways:

Your Product Owner should never, ever be assigning work to the team.
Your "developers" and "QA people" are not on the same team, or not working closely enough together within the same team to meet the ScrumScrum's definition of a Development Team. A good Scrum team should contain all the skills needed to meet each Sprint Goal within the Definition of Done.
Quality assurance doesn't sound like it's part of your Definition of Done.
You have deadlines instead of iterations with potentially-shippable increments.
The team has accepted stories it may not have the bandwidth to complete according to the Definition of Done.
Your team (or teams) are not on schedule for successful completion of accepted work, but no one has identified a root cause or actionable impediment, or asked the Product Owner to consider an Early Termination and a return to Sprint Planning.
A team with chronic resource constraints is either not following the Scrum methodology properly, is consistently mis-estimating tasks, or treating velocity as a management target. Fix the process!

You may have other process problems, too. However, these are the ones that really stand out for me, and I generally recommend teams start with the low-hanging fruit.

How to Fix Your Team's Processes

Here are some suggestions for improving your processes. Feel free to adapt or refine the suggestions to fit your specific team and organization.

Enforce the Scrum framework rigorously.
Ensure that Product Backlog stories are properly refined, and granular enough to fit within a single Sprint.
Ensure the team uses Sprint Retrospectives to inspect-and-adapt its estimating practices and its Sprint Planning Process.
Ensure the team only accepts work into each Sprint that fits within the established velocity range, while still providing enough slack for unforeseen events. Don't fall prey to the %100 utilization fallacy!
Ensure unit tests and acceptance tests are part of your Definition of Done, and make sure the whole Development Team shares responsibility for swarming over stories that need additional resources.
Whenever the Sprint Goal may not be met, meet with the Product Owner to refine scope or request an Early Termination.

You may certainly find other ways to improve the process, too. Don't stop there; Scrum (and agile practices in general) are all about continuous process improvement!

What's Wrong with Your Team's Processes

When the deadline is tight and when there is not enough QA people, and Product Owner asks developers to join in with QA to meet the deadline.

Your process problems are legion. Let me count at least some of the ways:

Your Product Owner should never, ever be assigning work to the team.
Your "developers" and "QA people" are not on the same team, or working closely enough together to meet the Scrum definition of Development Team.
Quality assurance doesn't sound like it's part of your Definition of Done.
You have deadlines instead of iterations with potentially-shippable increments.
The team has accepted stories it may not have the bandwidth to complete according to the Definition of Done.
Your team (or teams) are not on schedule for successful completion of accepted work, but no one has identified a root cause or actionable impediment, or asked the Product Owner to consider an Early Termination and a return to Sprint Planning.
A team with chronic resource constraints is either not following the Scrum methodology properly, is consistently mis-estimating tasks, or treating velocity as a management target. Fix the process!

You may have other process problems, too. However, these are the ones that really stand out for me, and I generally recommend teams start with the low-hanging fruit.

How to Fix Your Team's Processes

Here are some suggestions for improving your processes. Feel free to adapt or refine the suggestions to fit your specific team and organization.

Enforce the Scrum framework rigorously.
Ensure that Product Backlog stories are properly refined, and granular enough to fit within a single Sprint.
Ensure the team uses Sprint Retrospectives to inspect-and-adapt its estimating practices and its Sprint Planning Process.
Ensure the team only accepts work into each Sprint that fits within the established velocity range, while still providing enough slack for unforeseen events. Don't fall prey to the %100 utilization fallacy!
Ensure unit tests and acceptance tests are part of your Definition of Done, and make sure the whole Development Team shares responsibility for swarming over stories that need additional resources.
Whenever the Sprint Goal may not be met, meet with the Product Owner to refine scope or request an Early Termination.

You may certainly find other ways to improve the process, too. Don't stop there; Scrum (and agile practices in general) are all about continuous process improvement!

What's Wrong with Your Team's Processes

When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline.

Your process problems are legion. Let me count at least some of the ways:

Your Product Owner should never, ever be assigning work to the team.
Your "developers" and "QA people" are not on the same team, or not working closely enough together within the same team to meet Scrum's definition of a Development Team. A good Scrum team should contain all the skills needed to meet each Sprint Goal within the Definition of Done.
Quality assurance doesn't sound like it's part of your Definition of Done.
You have deadlines instead of iterations with potentially-shippable increments.
The team has accepted stories it may not have the bandwidth to complete according to the Definition of Done.
Your team (or teams) are not on schedule for successful completion of accepted work, but no one has identified a root cause or actionable impediment, or asked the Product Owner to consider an Early Termination and a return to Sprint Planning.
A team with chronic resource constraints is either not following the Scrum methodology properly, is consistently mis-estimating tasks, or treating velocity as a management target. Fix the process!

You may have other process problems, too. However, these are the ones that really stand out for me, and I generally recommend teams start with the low-hanging fruit.

How to Fix Your Team's Processes

Here are some suggestions for improving your processes. Feel free to adapt or refine the suggestions to fit your specific team and organization.

Enforce the Scrum framework rigorously.
Ensure that Product Backlog stories are properly refined, and granular enough to fit within a single Sprint.
Ensure the team uses Sprint Retrospectives to inspect-and-adapt its estimating practices and its Sprint Planning Process.
Ensure the team only accepts work into each Sprint that fits within the established velocity range, while still providing enough slack for unforeseen events. Don't fall prey to the %100 utilization fallacy!
Ensure unit tests and acceptance tests are part of your Definition of Done, and make sure the whole Development Team shares responsibility for swarming over stories that need additional resources.
Whenever the Sprint Goal may not be met, meet with the Product Owner to refine scope or request an Early Termination.

You may certainly find other ways to improve the process, too. Don't stop there; Scrum (and agile practices in general) are all about continuous process improvement!

Source Link

created Sep 10, 2014 at 16:16

Todd A. Jacobs ♦

50.7k
7
60
181

What's Wrong with Your Team's Processes

When the deadline is tight and when there is not enough QA people, and Product Owner asks developers to join in with QA to meet the deadline.

Your process problems are legion. Let me count at least some of the ways:

Your Product Owner should never, ever be assigning work to the team.
Your "developers" and "QA people" are not on the same team, or working closely enough together to meet the Scrum definition of Development Team.
Quality assurance doesn't sound like it's part of your Definition of Done.
You have deadlines instead of iterations with potentially-shippable increments.
The team has accepted stories it may not have the bandwidth to complete according to the Definition of Done.
Your team (or teams) are not on schedule for successful completion of accepted work, but no one has identified a root cause or actionable impediment, or asked the Product Owner to consider an Early Termination and a return to Sprint Planning.
A team with chronic resource constraints is either not following the Scrum methodology properly, is consistently mis-estimating tasks, or treating velocity as a management target. Fix the process!

You may have other process problems, too. However, these are the ones that really stand out for me, and I generally recommend teams start with the low-hanging fruit.

How to Fix Your Team's Processes

Here are some suggestions for improving your processes. Feel free to adapt or refine the suggestions to fit your specific team and organization.

Enforce the Scrum framework rigorously.
Ensure that Product Backlog stories are properly refined, and granular enough to fit within a single Sprint.
Ensure the team uses Sprint Retrospectives to inspect-and-adapt its estimating practices and its Sprint Planning Process.
Ensure the team only accepts work into each Sprint that fits within the established velocity range, while still providing enough slack for unforeseen events. Don't fall prey to the %100 utilization fallacy!
Ensure unit tests and acceptance tests are part of your Definition of Done, and make sure the whole Development Team shares responsibility for swarming over stories that need additional resources.
Whenever the Sprint Goal may not be met, meet with the Product Owner to refine scope or request an Early Termination.

You may certainly find other ways to improve the process, too. Don't stop there; Scrum (and agile practices in general) are all about continuous process improvement!