Agile Software Development: Scope

Question 1

Scope

Answer 1

Finding the right size of the work and estimating required resources

Question 2

Scoping should be

Answer 2

Fast, easy, expose the unknown, estimates should be relative, not exact

Question 3

Who should not dictate the scope?

Answer 3

Customers, product owners, stakeholders

Question 4

who should scope a project?

Answer 4

The team discusses the work with the product owner

Question 5

Scoping process

Answer 5

1. PO adds and prioritize stories in the backlog
2. The PO and team discuss the work together during a planning meeting, including the definition of done.
3. the Team provides a relative estimate for each user story

Question 6

Story Points

Answer 6

Story Points - The numerical units of measure that agile teams use to represent the size, scope, complexity, and level of effort for user stories

Drive consensus and conversation to ensure understanding

Numbers are relative and not equal to hours, min, or days

Story points are relative, have a different meaning from team to team, and cannot be used across teams

Used to determine the velocity of a team.

Question 7

Components of User Story Estimates

Answer 7

Complexity

• How hard is the story to complete?
• How many steps do we have to take to complete it?

Size

• How big is it?
• How much of it is there?

Level of Effort

• The length of time it will take us?
• How many of us can work on it at the same time?
• How long did it take us the last time we did something like this

Unknowns

• Have we done this before?
• How certain are we that we can do it?
• What do we know?
• What don’t we know?

Question 8

When are estimates done?

Answer 8

During the planning ceremony

Done in Ideal Time

Question 9

What do big estimates indicate?

Answer 9

too much complexity and unknowns need to be split into smaller stories

Question 10

Who can estimate work?

Answer 10

Only the team doing the work

Question 11

Reducing Scope

Answer 11

User stories should be estimable.

If estimates are too big user stories should be split

When user stories are split, they do not have to equal the sum of the original story

Question 12

Ideal Time

Answer 12

The amount of time it would take to complete the user story without any distractions.

Do not factor in time out of the office

Do not factor in time spent responding to emails, or IM’s

Do not factor in meetings, events, happy hours, etc

Question 13

Relative Estimating

Answer 13

Relative Estimating - the art of estimating the size, scope, complexity, and level of effort for a user story, based on the size, scope, complexity, and level of effort of another user story

Question 14

Story Points

Answer 14

Story Points - The numerical units of measure that agile teams use to represent the size, scope, complexity, and level of effort for user stories

Question 15

Modified Fibonacci Sequence

Answer 15

Used for estimating story points

This modification allows for having unique values that force separation for estimation purposes and is still based on the original Fibonacci Sequence.

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100

Question 16

Estimation Techniques

Answer 16

Planning Poker
T-shirt sizing
Affinity Estimiating

Question 17

Planning poker

Answer 17

1. Each member gets a set of cards with the agile Fibonacci sequence
2. After discussing the user story, the team raises their chosen card at the same time
3. Misalignment means there is confusion about the user story so more discussion might be necessary
4. The team repeats if the estimates are not relatively aligned

Question 18

T-shirt sizes

Answer 18

Great for estimating epics

Great for new teams

Great for when there are a lot of unknowns

Team uses T-shirt sizes (s,m,l,xl) to estimate

Question 19

Affinity Estimation

Answer 19

Good for new products, with a lot of stories to estimate

To estimate team uses t-shirt sizes, coffee cup sizes, or Fibonacci Sequence

The team places similar user stories into the same bucket/lane

Question 20

What to do when the team disagrees on estimates

Answer 20

Teammate A thinks user story 1 is a 3. Teammate B thinks the user story 2 is a 13. This means something is not clear and the Product Owner and team might need to have a discussion to make sure everyone is aligned on what work is to be done.

If no time for discussion, move on and revisit the estimate later during the planning

When agreement can’t be reached choose the most conservative estimate

Question 21

Definition of Done

Answer 21

The DOD is the team’s agreement for everything that needs to happen for the code to be “done”

Question 22

Does the team have to take the DOD into consideration when estimating work?

Answer 22

Yes

Question 23

The product owners definition of done

Answer 23

Acceptance criteria provide the team with the parameters for implementing user stories

The acceptance criteria must be met in order for the story to be accepted as DONE by the product Owner

This requires conversation and transparency between the team and product owner

We demo the working software to the Product Owner to confirm that the acceptance criteria have been met

Question 24

The Teams definition of done

Answer 24

The Team’s Definition of Done is their agreement for everything that needs to happen for the code to be “done”. If any of the code is not developed to the standard of “done” that the team has agreed upon, then the team must keep working on it until it is complete. As teams are estimating, they should be considering what it will take to complete user stories according to the team’s definition of done.

Question 25

Why is it important to distinguish between the acceptance criteria being met and the Product Owner adding to the scope.?

Answer 25

During demos, the acceptance criteria might have been met, but the customer might want additional features. This is not an example of acceptance criteria not being met, but as scope creep. The additional requirements should be added to the product backlog and prioritized by the PO