Scrum - ANSWERS1. It is framework for complex work such as new product
development
2. It is an iterative and incremental approach which emphasizes on time-boxing.
3. It is a light weighted agile methodology and an alternative to the traditional
approaches.
4. Scrum does not encourage "Partially Done".
AnswerWhen do we use Scrum? - ANSWERSWhen the requirements are uncertain
and technology is unknown. In other words when the work is more unpredictable.
AnswerRoles in Scrum - ANSWERS1. Product owner
2. Scrum Development Team
3. Scrum Master
AnswerResponsibilities of Product owners
(Single Ring-able neck) - ANSWERS1. Business Value
2. Prioritize the product backlog
3. Final arbiter of the requirements questions
4. Focused more on what rather than how?
5. Vision and boundaries.
AnswerScrum Master - ANSWERS1. No management authority.
2. Moves impediments out of the team.
3. Keeps the team away from other distractions.
4. Doesn't have a Project Manager role.
5. Acts as a facilitator.
6. Gets the team out of the way for natural team self organization.
7. Helps people to train on scrum
8. Promotes improved engineering practices.
9. Enforces time boxes, provides visibility.
Time Boxing: Having a limit on time availability for meetings etc.
10. Captures imperical data to adjust forecasts.
11. Makes sure scrum artifacts are available.
12. No decision making authority during the sprints.
13. Increase rigor in the definition of done.
,http://ScrumMasterChecklist.org
AnswerArtifacts - ANSWERS1. Product Backlog
2. Product Backlog Item (PBI)
3. Sprint Backlog
4. Sprint Task
5. Sprint Burn down Chart [x: Days spent y: Amt of work]
6. Product/Release Burn down [x: No. of sprints=average velocity] [y: story points]
AnswerProduct Backlog - ANSWERSA list of anything we might ever do. A PO
prioritizes them high to low.
Anyone can add into it. But the PO is responsible for the prioritization.
It does not contain task only PBI (Product Backlog items) in user story format or use
case scenarios.
1) Everything that the team would do through out the project.
2) Visible to all stakeholders.
3) Any stakeholders can add items.
4) Constantly re-prioritized by PO
5) Items at top are more granular than items at the bottom.
6) Maintained during backlog refinement meeting.
AnswerPBI (Product Backlog Item) - ANSWERS1) Specifies what more than how?
2) Written in user stories
3) Has a product wise definition of done to prevent technical debt
4) May have item specific acceptance criteria
5) Effort is estimated by the team ideally in relative units.
6) Effort is roughly 2-3 people days or smaller for advanced teams.
AnswerHow long is a well formed PBI towards the top? - ANSWERSNo longer than a
quarter of a Sprint.
AnswerForce Ranked - ANSWERSThere is only one thing at the top of the prioritized
product backlogs. Getting an organization to do that is considered a break through.
AnswerSprint Backlog - ANSWERSCommitted to do right now.
It has an end date.
Committed Backlog Items representing the what
Sprint Tasks representing the how
Scope committed is fixed.
Team will discover additional tasks needed to meet the fixed scope commitment during
sprint execution
Referenced during the daily scrum meeting.
Visible to the team.
1) Committed backlog items
, 2) Tasks not started
3) Tasks in progress
4) Tasks completed.
AnswerMeetings - ANSWERS1. Sprint planning meeting
2. Daily Scrum
3. Sprint Review Meeting
4. Sprint retrospective meeting
5. Backlog refinement meeting.
AnswerBacklog Refinement Meeting/
Product Backlog Grooming/
Backlog Estimation/
Story Time - ANSWERSTime Box: Same duration each sprint(5% of every sprint
activity) 4 hours
Some days before the Sprint Review Meeting to give the PO a little time to prioratize the
user stories.
PBI (Product Backlog Item)- INVEST-Independent, Negotiable, Valuable, Estimable,
Small and Testable
Purpose of Meeting:
a) Estimation of effort
Effort Estimation Techniques:
1.Planning Poker
2.T-shirt sizes
3.Relative Mass Valuation
b) Clarification of requirements
Decomposition of large PBIs into small user stories.
Strategies to split a PBI into smaller user stories:
2 types- horizontal and vertical splitting.
Horizontal Splitting- Goes with applications layer or the kind of work. This again
becomes like the water fall model and hence not encouraged.
Vertical splitting-
1) Split by workflows
2) Split by business rules
3) Split by happy/unhappy flow
4) Split by input options / platform
5) Split by datatypes or parameters
6) Split by operations
7) Split by test scenarios / test case
8) Split by roles