Planning and estimating a project can be difficult because it involves so many unknowns particularly near the beginning of a project. There are several Business Analysis tools that can help. This article is to provide an overview of some of these and an explanation of:
- Why they are useful for estimating;
- When best to use them; and
- How they correlate with each other.
Context diagram
A context diagram can be used as a black box view of a project or system. It sets out all of the human and system interactions. It can be worked out at the early stages of a project as it serves a useful purpose for scoping and planning out who needs to be involved. It is useful for estimating because it enables a view of how many different teams and systems are impacted to gain an understanding of size and complexity. If there are many different stakeholder groups then it will take longer to identify all of the different types of needs and if there are many external systems then there are technological interface considerations to understand. It was originally designed to show the context for systems but could be used in a business context also.
The diagram below is a context diagram to show who directly interacts with a complaints system.
Business and systems use case model
A context diagram can be turned into a use case model by adding use cases. It turns the black box into a white box by adding details of what is required. Use cases can be thought of as user end goals. For the purposes of the use case model and planning they do not need to go into any more detail.
A business use case model shows goals regardless of whether system driven or manual driven and provides further clarity on the scope of the project.
A systems use case model is specific to the goals of the systems for development and will show the use cases in the different system boundaries in scope. It will show lower level goals to some of the business use cases. To complete the use case model at this level will mean that the high level solution architecture will need to have been decided.
Estimates can then consider the number of use cases, size (small, medium, large) and complexity (simple, medium, complex). It also allows agreement as to what is in scope and allows prioritisation. If there are a number of use cases and limited resources the model can be used to gain a consensus on prioritising what needs to tackled first and what possible phases or iterations are required. The human and system interactions represented in the earlier context diagram are knows as actors in the use case setting. Each use case is related to at least one of these actors. This is useful for planning because they can be used to identify involvement and at what stage.
For agile purposes breaking the project down into goals enables the work to be planned into iterations. The use cases can be used for working out the user stories as described in the next tool.
Another benefit of drawing out a use case model is that it gives a picture on a page of the whole project or systems in scope on one page which is easy to understand. This will help avoid overlaps and duplication of work.
See diagram below of how the context diagram can be turned into a use case model. This shows the uses cases for a complaints system.
User stories
Some user stories can be identified from the different user groups and goals identified earlier in the use case model. They provide slightly more detail in that they are written in sentence format stating the user group, what they want to do and why. They can be specified at different levels. In larger use cases turning a use case into a user story may be too large for a typical agile 2-4 week iteration cycle. These are often known as Epics. They can still provide an idea of size and complexity for estimation, form the bases for discussion in breaking the user stories down into feature level and for prioritising. They also play a role in identifying releases of the software for example and ensuring the mini goals identified at feature level relate back to the higher-level goal.
When it comes down to iteration planning in agile the user stories need to be broken down to feature level, must be able to add business value and can be achieved in an iteration. Planning starts with a product catalogue which includes the user stories in priority order. Estimates are required on what can be achieved in each iteration. The product backlog has to be regularly monitored and amended as priorities may change and refinement may be required to work out what can be fitted into an iteration. At the end of an iteration there needs to be at least one feature completed at the end of it. Planning in agile is therefore extremely important to focus on completing on each of these mini achievements. Requirements are not specified at a detailed level as these are worked out in more detail with regular discussions and showing a prototype throughout. The user stories are required to agree upfront which feature of the system is going to be developed to ensure focus.
An example based on the previous complaints example could be:
As a complaints team user, I want to record complaint details so that we can maintain a record of complaints received.
Summary
Whatever project methodology is being followed planning and estimation is necessary to understand resources required, delivery timescales and to understand what can be achieved given project constraints. The techniques described above help with these. The context diagram ensures that external interactions are considered, the use case model provides an overview of what needs to be achieved and user stories help to identify what goals can be achieved in smaller chunks of time.
Thoughts? Questions? Please share in the comments.
