Two-part epoxy is a pretty neat invention. Epoxy is a co-polymer formed when two chemicals come together. They are known by different names, but one chemical is a resin or compound, and the other is known as a hardener or activator. Each chemical is pretty lifeless by itself, but the second they come together they form a useful adhesive.
The protective epoxy encasing is used in many consumer applications, the marine industry, and even aerospace. The point to remember is that nothing will happen until these two chemicals are removed from their separate vials and combined. That’s when the newly formed epoxy becomes extremely useful and powerful.
Similarly, the sprint planning process used in the agile with scrum development really consists of two meetings. The first meeting in the agile with scrum sprint planning process is to determine what will be done in the next sprint. The second meeting is to determine how this agreed-upon work will be done.
You will end up with very powerful and long-lasting results once these two meetings have occurred and the results are combined. If you have one meeting without the other or never combine the results, chances are extraordinarily high that nothing will happen. Your next agile with scrum project will sit there like two inert vials of chemicals that have never met.
What are these two agile with scrum sprint planning meetings, and how can you get the most out of the agile with scrum planning process?
The Agile with Scrum Sprint Planning Process Part I – What Will We Do?
The first agile with scrum sprint planning meeting focuses on what will be done during the next sprint. The product owner is the driver and brings out a list of stories important for the upcoming sprint. Stories are what users want the software in development to accomplish. For example, a user needs the software to sort and filter the final set of products returned by the application or, the user needs to be able to select a product and put it in their cart for purchase.
How does the product owner determine what products will make it into the next sprint? There are a number of ways:
- Carry-overs from the previous sprint: Typically, a handful of stories may not have been finished in the previous sprint. These are good candidates for inclusion in the current agile with scrum sprint. The product owner determines what stories are still relevant, and includes and prioritizes them accordingly.
- Feedback from the Users: The nature of the agile with scrum development methodology is that it responds quickly to feedback from the user. Additionally, agile methodology believes in releasing smaller sets of functionality more frequently rather than waiting on massive amounts of functionality released infrequently. This allows users to assess the newest release and say what they like or don’t like about the functionality. This feedback becomes part of the product owner’s prioritization process.
- A Changing Marketplace: A third area that provides stories to be included in the next release is what the marketplace is doing. Competitors may have come up with a new feature that you need to include in your software. Or, there may be an opportunity to optimize software with new functionality.
Once the product owner determines the list of stories to be included, she will discuss it with the team. They will vet out each story based on their current understanding with questions, ideas, and clarifications. The team then determines whether or not to include it in the next agile with scrum sprint. They will already have an idea of how long each story will take to implement as the estimating work has been done prior to this meeting. It’s now a matter of filling up the development cart with the number of hours allocated for the next sprint.
For example, it may be a two week sprint with four resources working full-time at a 75% utilization rate, which allows for 240 hours (more on the different types of estimating measurements later) to be applied toward these stories. The team picks those stories that add up to this number of hours.
A word of caution for teams that are new to the agile with scrum sprint planning process: be careful to not over-commit. It’s easy to be optimistic early on, but when the team realizes that they won’t be able to meet their commitment, it only leads to disappointment and frustration. It’s better to under-commit and over-deliver than the other way around.
Notice the delineation of responsibility that is also occurring at this point in the agile with scrum sprint planning process. The product owner determines the prioritization of what will be worked on, whereas the development team focuses on the viability of that selection and further hones that list.
You now have the first part of the agile with scrum sprint planning process; a prioritized and agreed upon list of activity that will make it into the next sprint. You’re now ready to move into the second part, which is deciding how the work will be done.
The Agile with Scrum Sprint Planning Process Part II – How Will We Do It?
The development team now gets their hands on the list of stories that everyone has agreed to undertake for the next sprint. They begin breaking the stories down into tasks and activities and doling them out to the team. There is a give and take as ‘progressive elaboration’ occurs. Team members begin working on their tasks. However, software development falls into the realm of ‘you don’t know what you don’t know.’ Once more information is uncovered about the task it may need more hours to complete. This is discussed with the team and ultimately product owner as it may jostle some of the other high priority stories on the list.
The team will get better at estimating durations over time. They may even consider using some of the alternate estimating measurements below:
- Number of Hours: This is the most common and easy to understand concept of estimating. The team calculates the number of hours it will take to complete the stories against the actual number of hours available.
- Number of Points: Points can be assigned to various tasks based upon their level of complexity. Points are then tallied up until the maximum number for the current sprint has been reached.
- Number of Tasks: Tasks can be counted if they are similar in size for the sprint. Tasks are added to the sprint until it has reached its allotted number.
Determining WHAT you will do does no good unless you know HOW you will do it. Knowing HOW you will do something but being unsure of WHAT you are going to do is also not good. Both elements carry equal weight when trying to get the most work out of your team and fully utilizing the agile with scrum sprint planning process.