Highlights
- Sprint Planning
- Estimation
- Sprint Goal
- Team Capacity and Velocity
Scrum Meetings – Sprint Planning
Previously defined events are used in Scrum to create regularity and to minimize the need for extra meetings. All events are time-boxed events, such that every event has a maximum duration. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Who Should Attend?
In Scrum, the sprint planning meeting is attended by the
- product owner,
- Scrum Master and
- The entire Scrum team.
- Outside stakeholders may attend by invitation of the team, although this is rare.
Why we need Sprint Planning?
- Collaboration and team building
- Common understanding of the product
- Task discovery, Task Assign
- Task prioritization
- Task estimation
- Knowledge and skill set improvement
- Different perspectives
Product Owner identify the items with the greatest value and works towards getting them to a ready state. During Planning make sure to discuss following:
- Assign a relative story point value
- Remove dependencies
- Create testable examples
- Define acceptance criteria
The Product Owner is responsible for declaring which items are the most important to the business.At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint.The Development Team is responsible for selecting the amount of work they feel they can implement without accruing technical debt.
The team “pulls” work from the Product Backlog to the Sprint Backlog. If the top of the Product Backlog has not been refined, a portion of the Planning meeting might be spent doing this. Toward the end of the Sprint Planning Meeting, the team determines how it will accomplish the work. For example, they may break the selected items into an initial list of Sprint Tasks.
Sprint Planning answers the following (Scrum.org):
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
Sprint Goal:
Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why they are building the Increment. The sprint goal is used for quick reporting to those outside the sprint as well, there are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item (user story) in detail. The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog.
Examples of good and bad goals
- Bad: “Complete all 6 stories we pulled in the sprint”
- Doesn’t add information to enable good team decisions
- Bad: “Develop the Daily Monitoring application”
- Completely fuzzy, Big scope. How can you to tell when / if you’re done?
- Better: “Architecture design for Daily monitoring ”
- Can be achieved within a sprint
Determining Velocity
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. It’s calculated at the end of a sprint by adding up all of the completed user story point estimations and averaged out over the course of several sprints. For example, if in Sprint 1 the team completed 35 story points, in Sprint 2 they completed 25, and in Sprint 3 they completed 30, the velocity would be 30.
35 + 25 + 30 = 90/3 = 30.
Velocity is unique to every team. So never use another team’s velocity to plan your sprint. Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint. By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.
Ideal Time
How long something will take to develop if its all you work on and if no one interrupts you and everything you need is available with you like requirements, resources and all access?
Ideally speaking, each day has 9 hours and for 5-working days, each week has 45 hours
But Instead Each day has something like this:
- 1 hours of meetings (Scrum Master Responsibilities, Backlog Grooming, Engineering capacity reduction (in hours, Daily Scrums and Weekly Planning meetings)
- 1 hour for Lunch
- 1 hour for email
- 6 hour left for the projects
Available Hours = Idea Hours - (PTO hours - Holiday - Lost Work - Meeting hours)
So actual productive hour for a particular team would be 6-hours a day and everyone from the team should be able to log their hours accordingly. By this calculation, Project manager and other stake holders can assume the capacity of the team and they can plan based on the math, how much work should be planned for upcoming iteration. There is no standard recipe for a successful deliverable team, one would have to inspect and adapt and distribute the work among themselves.
