Iteration Goal Poker: Defining a Goal for Your Iteration

DZone 's Guide to

Iteration Goal Poker: Defining a Goal for Your Iteration

Getting developers to fully align on an iteration goal can be difficult at times, as everyone sees things differently. See how one Agile team deals with this issue.

· Agile Zone ·
Free Resource

In a past article (see here) I've discussed iterations and goals or objectives. I stressed the idea that being iterative in your development activities is not enough. You and your team must also be focused while working in the iteration and this is facilitated when you have a goal or objective.

Sometimes I've been asked how a goal or objective can be defined. It's easy to speak about defining goals, but sometimes organizations need to have a precisely defined process. So, here's my proposal and here's what I call it: Iteration Goal Poker.

Iteration Goal Poker

I make use of BPMN to show a process diagram for Iteration Goal Poker. Following the picture, I explain the process. The process is meant to be run in an iteration planning meeting (or whatever your company does that is akin to a planning meeting).

Image titleFigure. Iteration Goal Poker process diagram.

The first activity in the process diagram, Discover customer/user expectations, accounts for understanding what the customer/user wants or expects at the end of the iteration, provided you have explained to him/her that you will be working in an iterative fashion. Although the activity lies in the "Development team" lane, this is only for the sake of simplicity. But please note that not only the Dev team is involved in this activity. You have to consider the participation of the customer, user, or Product Owner and don't be afraid to include other stakeholders.

The next step is to have your team members write down a goal privately, that is, do not allow them to show other team members what they're writing. The vertical bars in the activity indicate it is a multiple-and-non-sequential-instances one. Thus, at this step, writing down a goal is something every developer in your team is doing. When all developers finish writing their own goals (which is depicted by a document with three bars indicating multiple instances), next step is to compare the developers' written goals. Here comes the most important question: are all the developers understanding, at the same level, the same iteration goal? If one developer says his written goal is "to provide an interface for validation of data gathered from services A and B," and another developer says his written goal is "to integrate, and test integration, for services A and B," then you know that there is no common goal among the developers. The main conclusion of this is that your team cannot be focused on an iteration goal because they are not aligned with the goals of the organization.

What's next? To discuss differences and gain insight into why some developers understood things differently. This activity, as the first one, should involve a customer, user, Product Owner, and any other invited stakeholder. For example, the above-stated project to "provide an interface for validation of data gathered from services A and B," is probably aiming at the correct goal (because it is describing expected functionality), but you have to listen to all developers because nobody can assure a priori that one goal is correct and others are not. Note that discussing differences doesn't mean crafting goals. Neither write nor impose goals here. Let developers work alone again in writing. This is a way to systematically approach a new goal and it is also an aid to less experienced developers who sometimes feel intimidated by more experienced ones. Thus, when the discussion is over, you go back to write down a goal, again.

When the team feels there are no big differences in what each team member understands as the "iteration goal," then an iteration goal is written and published (this is the last activity, which is not marked as multiple instances because you end with one commonly understood goal). 

You can run the process for two or more iteration goals, although, as I stressed in a previous article, be careful with being flooded with too many goals. Having too many goals is almost like having no goals.

Final Words

In my experience, the ideal number of iterations is from 2 to 3. In very rare cases, you could end up taking more than 3 iterations to define a goal. If this is the case, the problem may lie in the definition of requirements, rather than in the goal's definition itself. Also, note that in order to avoid being flooded with too many goals, you shouldn't be running this process more than 3-4 times (i.e., no more than 3-4 iteration goals).

The work products depicted in the diagram are the required ones. You can freely use any other work product (e.g., a template) if it helps to run the process.

I strongly recommend you to read the two articles I've left as references.

Try this! And please feel free to comment with your insights gained from using this proposal in your specific environment.

agile, iteration, iterations, sprint goals, sprint planning

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}