Agile Up Front Analysis

16 Jul, 2007

One of the most visible aspects of agility is making decisions when they are needed, and not making them all up-front, before any development work is done. But some decisions are needed before the rest of the project is executed.
An agile approach to software development has many advantages in most organisations. Because change is inherent, in business needs, in technology, in knowledge, in people, it makes a lot of sense to use a process that takes change as a given and embraces it, instead of trying to defend against it.
One of the tenets of agile approaches is to decide things as late as possible. At the same time, we want to make software that people will use and like and that has real value to them. And sometimes these two goals are at odds with each other.

The traditional way to achieve this, is performing extensive requirements analysis before a project starts. All involved in the systems that is going to be built (the stakeholders) should tell upfront what they expect of the system, and after carefully balancing all needs, a list of requirements is delivered which is sent to the software design and development teams.
In an agile approach, many of the requirements gathering techniques used in traditional requirements management still make sense. The upfront analysis approach does not, as it does not take into account the fact that requirements change. People change their minds or gain a better understanding of their needs, laws change, budgets change, political landscapes change.
The usual agile approach is to finalise the requirements, and their relative prioritities, for one iteration just before that iteration starts. Refinement is even possible within the iteration. The requirements should be as detailed as necessary; not more, not less. This means that a requirements engineer not only talks with business stakeholders, but also with his primary customers: the developers, who are going to use these requirements.
Many agile (and non-agile) projects however start too fast, forgetting to think about issues that do need to be addressed before the first iteration. The risks of producing the wrong software are too big if these issues are ignored.
These issues include the business purpose of the project, the list of people and systems involved (the stakeholders), the scope of the work and the most critical constraints.
Depending on your organisation, this could be written down on one or two sheets of paper, or require a more rigorous analysis and report.
If you don’t, you run this risk of:

  • making something that doesn’t fulfill a business purpose, so it will be seen as a waste of money even if something is delivered [business purpose]
  • leaving out stakeholders and their requirements, leaving people unhappy at best, and making the result useless because it omits important functions or interfaces at worst [stakeholders]
  • including costly features that are outside of scope and could have been more economically implemented in another project or system (or leaving out important features that could have made the system more worthwhile – because of an incorrect assumption about the scope) [scope]
  • getting the wrong people on board, like oracle developers to extend a java system, or not being able to run on existing infrastructure, or not working towards an important deadline [constraints]

So in any project, even in an agile project, take time for a project blast-off in which these important issues are addressed, or else the success of your project is a complete gamble, no matter how good the team is.
After the blast-off, requirements management is part of the agile process, managed by the product owner, who is a true part of the agile development team.

Newest Most Voted
Inline Feedbacks
View all comments
Machiel Groeneveld
Machiel Groeneveld
14 years ago

In Scrum a project is seen as an exploratory process. Every sprint some working software is delivered. The main purpose is to collect feedback and therein lies a risk: the risk that stakeholders don’t know what the business case is (or should be) and give the wrong feedback.
Agile is about how to develop software, it’s still pretty vague on how to get from (hidden) business needs to requirements. So as long as we can’t do real time business requirements gathering and stakeholder analysis we’ll just have to do it up front.

Lars Vonk
14 years ago

Good points Erwin.
I think when you use a process like Scrum you are kind of forced in doing some upfront (not in-depth) analysis of your stakeholders and requirements. If you don’t do this the Product Owner can not have a product backlog with the features that need to be implemented. I think in Scrum you should always have a backlog of approx three months ahead of work to do. Also before starting a project you should at least have a vision and some milestones defined for your project (these can be vague) otherwise don’t start it.
The pitfall in upfront analysis however is that you go in to deep and to detailed for features that you are not going to implement for a one iteration.

Explore related posts