This post is part of the series “Z2A: From zero to agile”.
Have a project goal
This is not actually an agile specific recommendation but a general project management practice; you can refer to my posts with the tag *PMI* for more details.
Anyway before going to the next topic, let’s make sure this is consolidated in your project: it shall have a proper goal, a vision. Not the requirements, nor the features neither the stories but what is the ultimate goal of this project? At a high level, what do the financial sponsors want to get out of this project?
At the end if you don’t know where to go, then any road will be the same…
How to form the goal: start from the biz case
Of course, every project or product needs to state a business case. In an agile process, you create the business case using face-to-face commitment techniques with the key stakeholders to ensure that there is a firm understanding of and commitment to why you are doing the project.
Involve the product owner and the financial sponsors, in case make a workshop.
Remember: the shared deep understanding of why a project will be beneficial to the business is much more important than the actual business case you can print and read. Spend all the necessary time for it.
A good way to create a proper goal is to use the SMART framework.
Write down the goal
The goal can usually be expressed in a few sentences, which can be collected in one single page. It should be the first page of your project charter.
Once you have it, hang it on the wall or put it in the first page of your project intranet, so that everyone can always see it and remember what is the project final scope.
You would be surprised on how many projects don’t have a proper goal in place.
Examples of project goals could be “redesign our e-commerce website in order to improve customer conversion of 30%” or “make our government organization web site accessible” or “create a new mobile app that will do x and z”.
Can the goal change?
Short answer: usually not, but it will.
Sure, the requirements can change during the project lifetime but the goal you assume is defined at the beginning of the project and stay the same.
At the end, you need to have a strategy, a big picture, otherwise how will you be sure that the requirements will deliver values and how can you take sound decisions when changing them or bringing in new requirements to leverage new business possibilities?
But the reality is that you have to be prepared to have to change or adjust your goal as you discover more opportunities along the way. We may create a vision first, but the vision will be being challenged and updated. The agile business case stays with the product owner and the team, being constantly questioned, changed and proven.
My suggestion is that if the goal changes so much that is completely different (like if you pivot your start-up product, from “creating a system to share images for online massive multi-players” to “creating a system to share pictures with everyone”) then it’s better to close that project and start a new one.