Ivar Jacobson's Blog

Over the last few days a number of people have asked me the same question: “How can we get more accurate requirements?” While I agree it is not nice to answer a question with a question, in this case you might bend etiquette a bit because in reality this question can be hard to answer. For example, why is it necessary and which problem does it solve? Or, what exactly do you mean with accurate?  And do you have accurate requirements and you want more of those? And in that case, more than what? Or do you have inaccurate requirements which you want to become more accurate? And if so, how much more?

You might say: “Hey, that’s just playing with words”. Well, that’s right and so is writing and communicating requirements. In order to get accurate requirements you need a number of things. However, an often overlooked element to writing accurate requirements is understanding the structure of language and how language is perceived. Read the rest of this entry »

Each iteration is unique. It involves undertaking a unique set of activities to produce a unique version of the product that objectively demonstrates that the iteration objectives have been met.

Because of this uniqueness, each iteration requires its own iteration plan. The iteration plan contains the details of all the activities that the team is required to do to meet the iteration objectives. The amount and style of activity-level planning required for a project is dependent on many factors including the project risk, team size, experience levels, and the manager’s own preferred management style.

For some projects, an informal plan describing the goals to be achieved and listing the tasks to be undertaken is sufficient; you can leave the scheduling and allocation of the activities to the development team. Other projects require more comprehensive plans that describe the activities and their allocation in greater detail to work out the dependencies between the tasks to be performed by the various team members. Read the rest of this entry »

Traditional project management approaches focus on planning in detail, assigning the resulting tasks to people and then tracking "progress" as measured by completed tasks. The problem with measuring progress this way is that completing a task, while important, is hard to correlate with progress against the overall goal - just because you've completed 20% of the tasks does not mean that you're 20% done - and for tasks that take a long time to complete the self-reported estimates of "percent complete" is often merely "wishful thinking".

My preference is to measure progress in a concrete and measurable way - in the form of tested scenarios, following an iterative project management approach.  In other words, planning works iteration by iteration, with each iteration developing and testing one or more scenarios.  At the end of each iteration, you have a set of developed and tested scenarios, making progress easier to measure: knowing that you've developed and tested 20 out of 100 scenarios is a lot more meaningful than knowing that you've completed 20% of the tasks - especially if those tasks are focused on creating documentation rather than running and tested code.  Scenarios correlate nicely with business value - each scenario should be useful to at least some subset of the stakeholders.  In my view, only when you've successfully tested a scenario can you claim to have "earned value".