Agile Product Ownership : A Guide to Leading Agile Teams and Creating Great Products by Bart Gerardi

Author:Bart Gerardi [Gerardi, Bart]
Language: eng
Format: epub
Published: 2013-12-21T18:30:00+00:00

Planning Cycles

Depending on the actual flavor of Agile that your team is using, you may call the planning cycle by a different name. Sometimes they will be called sprints, other times they will be called iterations. Some organizations will just call them versions, and number them from one to infinity. Vocabulary does matter a bit in this business, but not enough that anyone should enforce any name on the concept of determining what to do, doing it, and then looking back on what you have done. No matter what form of Agile you are using, you must have all three things.

The only word that you want to stay away from with this concept is the word “release.” In most Agile literature and teams, a release is something that is actually released to the public. Several iterations, sprints or whatever your teams calls them are what make up a release. For our purposes, I’m simply going to call them cycles.

And the first thing you need to do when planning for a cycle, is to determine the goal you are trying to achieve. Defining the goal of the cycle. As you have probably figured out by now, one of the tenets of Agile development is to understand your goal before you start doing anything. If you do not know what you are doing, then there is no way to know if you are doing it right.

The goal of a development cycle should be to move the product closer to being able to be released to customers. A good goal is both achievable and meaningful; it must be a goal that isn’t vague like “improve the customer experience,” but it should be substantial enough to guide the team’s actions during the cycle. The goal should be reachable, even if all the items in the backlog are not completed. If removing a single story from the cycle completely invalidates the goal, then your goal isn’t broad enough.

The cycle goal cannot be done by the product owner in complete isolation. Like all other tasks, the more that the entire team is involved, the better the outcome will be, and the more committed the team will be to achieving that outcome. It also helps focus the team on the items in the backlog that help reach the goal. If there are items that people are working on that won’t help with reaching the goal, they should stop working on them. It’s the goal that helps facilitate this discussion.

Identifying and communicating the goal can and should require changes the product backlog. Items on the top of the backlog that don’t help reach the goal should be demoted, just as items that are lower on the priority list that are critical for the goal should be lifted. Once the goal has been identified and agreed upon, the backlog should be adjusted to match. You should never have conflicts in priority between what you are trying to achieve in a cycle and the priorities on the backlog. Doing so will just cause confusion in the team.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.