Sprint Planning Meeting
During our first official Sprint planning sessions, each meeting took approximately 2 hrs and more. Let’s examine how to make it more efficient and productive.
During our first official Sprint planning sessions, each meeting took approximately 2 hrs and more. Let’s examine how to make it more efficient and productive.
Sprint goals (also sometimes called epic) are 1 or 2 line board objective of the sprint:
E.g. “Implement Web-services API support for <xyz> product, so that the app developers can access the products backend capability”
The user stories and product backlog are the terms sometimes used a bit interchangingly. There is a slight difference. The user story describes an end-to-end product use case performed by a persona/ actor / user of the product. They have to fully functional and demo-able. They are created by the Product owner (PO) and written in the following format:
As a (role) I want (something) so that (benefit).
The PO comes to the sprint planning meeting with a list of user stories that are fully prioritized. It’s preferable to have a number of user stories that could roughly cover 2-3 sprints. 1 user story should not spill beyond a sprint. The PO should also come fully prepared with details explanations and steps behind the user stories and she should describe those verbally in the meeting.
During the course of this discussion, some stories are split, some joined together, you can create new user stories. Some stories may not strictly be from the “end user” perspective, but are from the Architect, Tester or a Deployment admin’s perspective. After the sprint planning meeting, the team comes out with the prioritized set of Sprint backlog that includes all these stories. Sprint backlog is a subset of product backlog that are committed for the current sprint.
The other artifact you create during the sprint planning is the Tasks associated with each Sprint backlog. Identify owners of the tasks and rough estimate to complete it. Please take care to create tasks like architecture, study/Knowledge Transfer, UI design, testing etc. – whatever that’s need to complete the story at its entirety. Do not take tasks as a group (like testing team, Jack & Jill), but keep it at the individual level. Also, the keyword is “task selection” – and not “task assignment”, as the team members normally chooses the task in consultation with all - and not assigned. The tasks have to be short – normally of 4-8 hrs chunk, so that all can see the progress continuously and you get the satisfaction of crossing out To-do’s daily.
To keep the planning meeting focused and short, don’t get into complete details of task breakdown. You can always do this offline and add new tasks to the list.
The PO can also be sending the User stories for the next sprint a couple of days in advance in the previous sprint. This allows the team to spend enough time thinking about the task breakdown before they come to Sprint planning meeting. Sometimes, if the user story is complex, or requires more analysis or architectural input, that itself could be a whole story for a sprint (e.g. "As an Architect/ Business analyst, I want to clarify ...")
The PO can also be sending the User stories for the next sprint a couple of days in advance in the previous sprint. This allows the team to spend enough time thinking about the task breakdown before they come to Sprint planning meeting. Sometimes, if the user story is complex, or requires more analysis or architectural input, that itself could be a whole story for a sprint (e.g. "As an Architect/ Business analyst, I want to clarify ...")
Load the team by ~70%, not 100% or more so that you can use the buffer for additional tasks that are discovered during the sprint.
At the end of sprint planning, the team should publish the Sprint goal/ epic(s) and high level user stories. This should be distributed, printed/ written and displayed prominently for all organization to see. This is the Sprint teams commitment to the organization and you must do everything to keep it!
Additional reading:
No comments:
Post a Comment