Agile Software Development: Scope Flashcards
Scope
Finding the right size of the work and estimating required resources
Scoping should be
Fast, easy, expose the unknown, estimates should be relative, not exact
Who should not dictate the scope?
Customers, product owners, stakeholders
who should scope a project?
The team discusses the work with the product owner
Scoping process
- PO adds and prioritize stories in the backlog
- The PO and team discuss the work together during a planning meeting, including the definition of done.
- the Team provides a relative estimate for each user story
Story Points
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.
Components of User Story Estimates
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?
When are estimates done?
During the planning ceremony
Done in Ideal Time
What do big estimates indicate?
too much complexity and unknowns need to be split into smaller stories
Who can estimate work?
Only the team doing the work
Reducing Scope
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
Ideal Time
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
Relative Estimating
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
Story Points
Story Points - The numerical units of measure that agile teams use to represent the size, scope, complexity, and level of effort for user stories
Modified Fibonacci Sequence
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
Estimation Techniques
Planning Poker
T-shirt sizing
Affinity Estimiating
Planning poker
- Each member gets a set of cards with the agile Fibonacci sequence
- After discussing the user story, the team raises their chosen card at the same time
- Misalignment means there is confusion about the user story so more discussion might be necessary
- The team repeats if the estimates are not relatively aligned
T-shirt sizes
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
Affinity Estimation
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
What to do when the team disagrees on estimates
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
Definition of Done
The DOD is the team’s agreement for everything that needs to happen for the code to be “done”
Does the team have to take the DOD into consideration when estimating work?
Yes
The product owners definition of done
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
The Teams definition of done
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.
Why is it important to distinguish between the acceptance criteria being met and the Product Owner adding to the scope.?
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
