Agile Walk Through - Free Beta



Requirements describe expectations about the result which should be produced (i.e. how it should behave, look and feel). They define necessary attributes, capabibilities or characteristics of the system in order to be valuable for the user.

In AWT requirements are superior design elements, and they are used as subjects of planning and as containers for tasks and bugs.

  • Requirements-list-hierarchy
  • Requirement-show-with-issues

Requirements are organized in a hierarchy according to chosen criteria (e.g. by modules and submodules of the system). More specific requirements or ones which modify the expectations of some requirement (which has already been implemented) are put as children of appropriate parent (e.g. Drag-And-Drop sorting of elements as a child of more generic Elements management).




You can create a requirement as stateless, draft or new:

  • Stateless requirements describe expectations which don't need any direct work (and won't have any workload items - tasks or bugs), or which act just as a container for other requirements.
  • You can create requirement as draft if there's not enough description to plan or estimate it. You can fill it with details and once it's ready - turn it into new.
    Draft requirements don't appear in project planning or workload.
  • New requirements are ready for planning and estimating (through creating of tasks).


Once requirement is new it can be prioritized and planned.

In iterative planning you can put requirement to selected backlog (release's, iteration's or project's) and prioritize it within this backlog using simple drag-and-drop.
If simplified planning is used requirements are prioritized in a single scope.


Tasks necessary to address the requirement are created and once work on any of these tasks starts, requirement receives started state. When last task or bug is finished (according to their lifecycle - completed or verified) the requirement is automatically turned into completed.


Once requirement is completed it can be checked against the description to make sure that all is done appropriately. Usually the person responsible for the describing the requirement (e.g. product manager) is the most qualified to make the final check and verify or reject it. Verification is an optional part of requirements life-cycle and can be enabled per project.

  • Requirements-list-to-verify


You can cancel requirement at any point - all not finished tasks and bugs included into this requirement will also be canceled. It will be possible to re-activate it later.

Estimating requirements

There are two ways to estimate requirements in Agile Walkthrough: precise (in time) and rough (in points).

To estimate requirement in a precise way you need to create all tasks necessary to address this requirement and get those tasks estimated by appropriate professionals, i.e. graphic design tasks estimated by art-director, programming tasks estimated by programming team-leader and so on. The estimation of the requirement is the sum of estimate times of all its tasks.

When you don't need enough information to do such estimation or when this precision isn't required you can estimate whole requirements rough way - in points. You can pick up your own scale (e.g. tiny requirements - 1p, average - 3p, big - 9p) and measure your velocity in points later on.

Finally you can combine both those approaches: first do rough points-estimates, and next do precise time-estimates.

Copyright 2007-2010 Agile Walkthrough