When you’re working within an agile management framework, you accomplish discrete tasks within the framework of a sprint. On the first day of each sprint — often a Monday morning — the scrum team holds the sprint planning meeting. The purpose of the sprint planning meeting is to
Establish goals for your sprint.
Choose the user stories that support those goals.
Break user stories into specific development tasks.
Create a sprint backlog.
Keeping your meetings short so that the development team has the time it needs to create the product.
Setting goals and choosing user stories during an agile sprint planning meeting
During a sprint planning meeting, the product owner and development team, with support from the scrum master:
Discuss and set a sprint goal.
The sprint goal should be an overall description supported by the highest-priority user stories in the product backlog.
Review the user stories from the product backlog that support the sprint goal and revisit and adjust the effort estimates as necessary.
Determine what the team can commit to in the current sprint.
The development team should agree and confirm it can complete the goal planned for this sprint.
Always plan and work one sprint at a time. Don't place user stories into specific future sprints Keep the ordered list of user stories up to date in the product backlog and focus on developing the remaining highest-priority stories. Commit only to planning for the current sprint. If any of the user stories don't fit in the current sprint, remove them from the sprint and add them back into the product backlog.
Creating tasks for the sprint backlog during an agile sprint planning meeting
After setting goals for the sprint and determining the user stories the sprint will fulfill during the first part of the sprint planning meeting, the scrum team
Creates the sprint backlog tasks associated with each user story.
Break the user stories into discrete individual tasks and allocate a number of hours to each task. Make sure that the tasks encompass each part of the definition of done: developed, integrated, tested, and documented.
Double-checks that the team can complete the tasks in the time available in the sprint.
Be careful about over-committing at the beginning of a sprint, especially in the project's first few sprints. The development team should target being able to complete a task in a day or less, for a couple reasons: Short-term goals promote productivity; and a short timeframe brings problems to the forefront quickly. If a team member is working on a task for more than a day or two, that task or that team member may need special attention.
If the tasks exceed the hours available, seek the project owner’s advice on which user stories to remove from this sprint.
Each member chooses a first task to accomplish.
Development team members should work on only one task on one user story at a time to enable swarming — the practice of having the whole development team work on one requirement until it’s completed. Swarming can be a very efficient way to complete work in a short amount of time.