Agile Methodologies have revolutionized application development AND influenced how business operates today. 

Day-to-day marketing, product management, finance and other activities can be overwhelming because there are so many competing priorities. The introduction of Agile principles such as prioritization, iterations, and sprints (moving planning to be quarter-to-quarter rather than an inflexible year-to-year) has helped businesses choose which opportunities to pursue and nimbly respond to market shifts and changes. Adopting Agile approaches has been a game changer for businesses worldwide.

However, there is little guidance in the Agile methodology for helping the business gain a clear vision and goals for a proposed product or project.

Iteration 1 typically starts with setting up the dev environment and writing infrastructure/core functionality stories, but if the business hasn't figured out what they want to do or what they need – nevermind what the priorities are – how can they get to Iteration 1 and write a story?

New projects aren't "born" neatly scoped with a clear strategy, goals and ROI. From my experience, new projects come from 4 places:

• Most common: An executive tells the team that there is a market need for a new site or app and the team needs to figure it out. Often, that's all the direction the team is given – they really do need to figure out what the project/product should be.
  

• The team or a team member realizes that there is a market need for a new product – and this needs to be defined further. The project needs to be sold internally, so the vision is developed during the buy-in process with the larger organization and other teams. 

• Organic creation – the team realized that the super-product should be broken into two (or more) parts. Sometimes, a product gets so big, it just makes sense to split it up. But where does that split happen? That often needs to be defined and scoping typically happens during the buy-in process with the larger organization and other teams. 

• Start-up case: A visionary has an idea, knows the market really well and knows what needs to happen next. This is the dream case for Agile – the project can kick-off right away. However, a lot of behind-the-scenes activities happens for the visionary to know his market and what they need. He has done his research and has a lot of data to support what needs to happen. 

Scoping a project and defining its goals is a unique activity that can take a month or two. However, it's not a project with tangible results; it is a project that results in an organizationally accepted PowerPoint presentation, site maps/wireframes/sketches, a few projection spreadsheets, and defined target metrics. 

To get to that vision, the business team often needs to get into the details and create a vision for what they want to do. Sure, we should be thinking about what we want to do as we go along in Agile ideology, but if the business team doesn't have a focus for what they want to do – the project will fail.

I have seen this happen too often. Technology decisions rather than business strategy starts to define the project if the business leaders don't have a strong vision. The business leads need to be focused on what they want this product to achieve.  

And what needs to exist for the business strategy and vision? A set of goals and ROI isn't enough. The business needs to:

• Understand the market
• Know who the customers will be and understand the market
• Be able to quickly identify the competitors (and speak to their strengths and weaknesses)
• Know what issues the product will solve (or does solve)
• List the core functionality this product needs to have at launch – understand the nice-to-haves vs must-haves
• Understand the general technical challenges to build the product – specifics happen during the process. But to make some initial scope decisions, the business team needs to be informed.
• Have metric targets and goals to prove the product is a success – and have a general idea of what will happen if those goals aren't met.

Often, user or customer experience will invited to the discussion to be sure that user/customer needs are addressed. The development team will be invited so the business team can better understand scope and costs and the technical barriers to entry. It takes a team to scope a project. 

Often there are sketches of what this project could be. This helps the business team have a visual to better understand what they want. By the time a story is written, there were a number of sketches that the business team created with user experience to develop their plan. Their process to get to a vision is iterative.

Some may call this getting into the details; I call this research to understand what you want to get. It's like building a house. 

How do you figure out what you want in a house?

• Visit a lot of houses
• Create a list of what you want in it
• Make sketches
• Talk to architects and designers
• Talk to builders
• Make more sketches
• Figure out how you want to feel in your house

You don't build a house as you go along with zero vision to guide it (or you can, but you may end up with a weird house!). The business needs to do a little research to understand what they want to "live in" before they start building anything. 

 

I'll be talking about this more at Agile 2014 in my session: Go From a Nebulous Vision to Iteration One in 3 Steps. Hope to see you! 

Feel free to contribute to the conversation about scoping Agile projects. I look forward to hearing from you.