The rule for planning a Sprint with Scrum effectively is having cristal clear the goals: they will guide the developers to the definition of the possible tasks and the best ways to realize them.
In the last articles about Scrum i talked you about its efficiency as a framework for the implementation of the Agile methodology and about roles in a Scrum team. I've also explained that with Sprint we mean a variable period of time during which the Scrum Team develop a "part of the software" that will be delivered functioning at the end of that period.
In order to program it in the best way possible there's the need to a Scrum team meeting: all of its elements have to plan the Sprint in a collaborative way. The planning phase have an established duration (max 8 hours for a month long Sprint) and the Scrum Master's task is to make the team complete the planning phase within the established period of time; He also has to make sure that the team members have deeply assimilated the objectives of the Sprint and are able to answer the following questions: how many tasks can I complete during the Sprint? In which way?
Definition of tasks quantity that are accomplished during the Sprint
The just formed development team will need to foresee exactly how much work will be everyone be able to do during the Sprint.
The Product Owner sets the goal for the Sprint and suggest the quantity of objects of the Product Backlog that will have to be done in order to reach the goal. Meanwhile the team is able to intervene to clarify potential doubts and to suggest changes to the lineup. The team have always the last word on the objects quantity that it'll be able to develop during the Sprint: Product Owner and team will try to find a deal close to the P.O. necessities and to the team's production capacity.
After that the number of functionalities that have to be developed has been setted, the team will define a goal for each single Sprint: this will be the guide and the motivation for pursuing the goal. This could simply be the function that will be added at the end of the Sprint: the important thing is that it has to be clear to developers and it has to help them working in tune. Thanks to the goal the team will be able to understand if the work is going in the right direction: otherwise developers can redefine the goals with the Product Owner.
Definition of the modus operandi for finalizing the goal
After defining quantity, it's time to think about the carrying out methods.
The union between the Product Backlog objects and their planning phase into the Sprint are known as Sprint Backlog. Developers have to take the Sprint Backlog and "rip it apart", dividing tasks in unit that often coincide with the daily working period. After that they have to divide the functionalities to develop: they'll decide who make what.
In this way, at the end of the meeting, the team will be able to tell the Product Owner and to the Scrum Master, the way in which everyone will work and will interface with the other ones in order to reach the goal.
At this point the team is ready to start knowing exactly where they have to arrive.
How much important are goals for you? In your projects are you always able to define them clearly? Let us know in the comments section below!
Thanks for reading the article.
For further informations contact us here or on Facebook or Twitter, where you can follow us to keep updated with our articles.
.jpg)
