AgileScrum-Blog#04 Sprint Planning

Jajvir, the Tech Lead of Jarotball (Company) is attending a Sprint Planning Session. During the session many factors has been considered while some not. Now, among the followings, which factor Jajvir should not be considering during the Sprint Planning?

• [ ] the team's velocity
• [x] the number of stories in the product backlog
• [ ] the stories that are ready
• [ ] the team's capacity

1. What is Sprint?

• Sprint literal meaning is a short race at full speed.
• It is one timeboxed iteration of a continuous development cycle.
• usually define a short duration of a Sprint up to 2-4 weeks.
• Within a Sprint, planned amount of work has to be completed by the team and made ready for review.
• Before Sprint Begins(The Planning Session)
  • Team collaboratively sets their target with Product Owner as “Sprint Goal” and plan their work in “Sprint backlog”. -Once the Planning Session Over (Sprint Begins)
  • As soon race starts after planning session, team work together to complete planned work effectively and make it ready for review by the end of that period.
• Pre-requisite of Sprint Cycle
  • High level User Stories readiness in Product backlog is the prerequisite of starting a Sprint Cycle.

1.1 Sprint planning

• Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.
• In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.
• Sprint planning is a collaborative effort involving
  • a ScrumMaster, who facilitates the meeting,
  • a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and
  • the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

1.2 What to consider and do in Sprint Planning

1.2.1 In Short

• ENSURE RIGHT SIZING BACKLOG ITEMS
• CALCULATING A COMMITMENT - use a combination of both team availability and velocity.
  • Determine Velocity
  • Determine Capacity

1.2.2 In Brief

1. Remind the team of the big picture or goal
2. Discuss any new information that may impact the plan
3. Present the velocity to be used for this release
4. Confirm team capacity
5. Confirm any currently known issues and concerns and record as appropriate
6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
7. Present proposed product backlog items to consider for the sprint backlog
8. Determine the needs, sign up for work, and estimate the work owned
9. Product Owner answers clarifying questions and elaborates acceptance criteria
10. Confirm any new issues and concerns raised during meeting and record
11. Confirm any assumptions or dependencies discovered during planning and record
12. ScrumMaster calls for a group consensus on the plan
13. Team and Product Owner signal if this is the best plan they can make given what they know right now
14. Get back to work

Sprint Analytics (i.e. a Dashboard) help Scrum Master and Product Owner to know the progress of Sprint in a glance.
The term 'Sprint' is mainly used in Scrum Agile methodology but somewhat basic idea of Kanban continuous delivery is also essence of Sprint Scrum.

---

Note 01: Product Backlog Vs Sprint Backlog

• Product Backlog: The product backlog is compiled of all the things that must be done to complete the whole project.

  • it’s not just a simple task list.
  • An effective product backlog breaks down each of the items on the list into a series of steps that helps the development team.
  • There must be a duration (start to finish for the team to know).
  • This process can be expedited with the help of a task management software.

    ITS NOT A STANDSTONE, is flexible and adjustable on the development team. By adjustable, it means: (i) Shrink- as the task is completed (ii) Grows- as the project grows

• Sprint Backlog:

  • The sprint backlog is like a subset of the product backlog.
  • The sprint backlog comes from the product backlog, but it contains only that item, or those items, that can be completed during each agile sprint.
  • Example: Think of it as the marching orders for the team as they go off on their short sprint.

    IT'S FROZEN FOR A TIME BEING, Unlike the product backlog, though, the sprint backlog is unchanged during the period of the sprint. It can be changed, but only during the sprint planning meeting, once agreed upon.
    

  What if there are items left unfinished? - they will be added back to the product backlog and addressed during the next sprint.

NOTE 02: Don’t Forget to Prioritize

• It’s always a good idea to prioritize the tasks on your product backlog from crucial to less important.
  • This is a task for the Product Owner, being the one most intimate with the needs of the stakeholders.
• While the Scrum Master would seem a logical choice to help with prioritizing.
  • Note: the scrum master is only there to help with the process, not with the product.

---

2. Solving Question through Elimination Strategy

Which factor Jajvir should be considering during Sprint Planning?

• [x] the team's velocity [S01: this is considered in Sprint Planning for calculating the Commitment]
• [ ] the number of stories in the product backlog [S02: Planning is concerned only of the Sprint backlogs, not the overall product backlogs]
• [x] the stories that are ready [S03: is considered in Sprint Planning, Through the Definition of Done, which could be reviewed]
• [x] the team's capacity [S04: considered in Sprint Planning For Calculating the Commitment]

2.1 Answer

Which factor Jajvir should not be considering during Sprint Planning?

• [x] the number of stories in the product backlog