13

Agile scope

The agile, lean and coaching tools in the next sections will help you to manage the activities you have mapped onto notes so far. This will help you to track the balance of your workload and measure progress. Agile is a method that focuses on managing and organising your workload as you work, rather than as a separate activity.

Using GROW to establish a clear understanding of the goal, the current reality and the options going forward, the next stage is to break down the work involved into manageable, and then actionable, requirements that can be prioritised and scheduled.

With an expectation of change and evolution of the requirements as time progresses, it is impossible to know and define everything from the start. What is necessary at the start is to get a good understanding of what each of the potential options might involve and areas that might prove difficult, so that we can establish if these are viable as early as possible. If, for example, one of the key requirements would be incredibly costly to implement, it may be that we test that assumption and validate these costs as one of the first activities.

Initially, we want to map out what we think is involved at a high level and make initial estimates, and then refine this over time. As a better understanding is gained, we can refine these estimates and make better informed decisions. Work can be broken down more easily as it becomes a priority, rather than trying to define everything exactly in micro detail from the start.

Starting with the basic plans enables more flexibility as work progresses. As the solution begins to develop, decisions can be made on the detailed elements and which changes are required.

Agile provides an adaptive approach to delivering solutions, based on current scenarios and needs. Initially, there may be a need to act quickly and identify changes we can implement quickly and easily in order to adapt and improve current outcomes. By mapping these current and future activities, we can begin to structure the work we do visually and identify these requirements.

Jobs to do

Building on the notes you have already created, start to map out all the current jobs you have to do, including what your role involves and for what you are responsible.

• Core jobs Map the jobs you do regularly as part of your working week. For example, selling widgets, making widgets, marketing widgets. Break down the key tasks involved: prospecting, purchasing, planning, organising.
• Supporting jobs Map the other jobs that you do alongside your main tasks: record keeping, reporting, team meetings, answering calls/emails, timekeeping and expenses, training, covering others’ work, pet projects, workgroups with which you are involved. Capture as many as you can.
• Additional jobs Think about the things you would like to do and for which you never get time. What are the things on your list that never get crossed off? If you keep moving something in your calendar, or find yourself repeatedly writing it on your daily list, it is a good sign it is something you should, could or would like to do, but the must-dos keep getting in the way.

Use different colours to represent different types of work or aspects of your job so that you can differentiate more easily between them.

Expect to add to this later as your mind recalls other elements that you may not be able to recall immediately.

Group the notes into different types of activities and review how your time is spent.

If the work is very dependent on others, then a workshop to establish requirements is a good way to map out their needs and the associated activities. Working together will help to establish priorities and what is important, which will feed into how work is structured and what elements should be tested and delivered early.

Working collaboratively with those who are dependent on the work you do can help to ensure that a state of collaborative working is maintained rather than the more rigid contracting and negotiation. By working openly and seeking feedback we can gain the support and backing of those we work with where the flow of information and an improvement of communication creates a better working environment and team culture.

By interacting and observing those with whom and for whom you work, you can develop a clearer picture of what is wanted rather than rely on written documentation and specification. Observing behaviour and questioning assumptions can help to provide a clearer picture of the requirements and foster a working relationship that continues to provide information that helps to deliver a more acceptable and easy-to-integrate relationship.

Jobs and user stories

Originally defined by Kent Beck (developer of Extreme Programming) and developed further by Rachel Davis, author of Agile Coaching, the purpose of user stories is to establish the current needs of the client, not to define the solution. By identifying why the solution is needed and what purpose it will serve, we can see how a solution needs to solve a problem. Unfortunately, often what a customer thinks they want and what they actually need are slightly different. It is only when a customer actually uses a product or service that they are able to identify whether or not it will work effectively.

If you are working on a specific project, mapping user stories is a useful exercise to help map out the job’s scope and requirements with those who use, manage or rely upon the solution in some way. User stories set out the different roles and needs associated with the goal, and build up a set of requirements based on benefits for use when developing a solution.

User stories help to establish the reality and the context in which a solution is to be delivered. By defining the user stories we gain awareness of the requirements from different perspectives to gain a greater understanding of what is needed and why.

The technique can be used personally or with colleagues, management, customers or partners to help see and understand the needs of others and how their roles are related. This tool can be used at a variety of levels to identify high-level benefits and gain clarity on minor details.

Establishing user stories collaboratively helps to ensure that needs and requirements are aligned from a number of perspectives, and that there is shared understanding and consensus. Rather than mapping processes and systems, user stories look at the interactions and needs of people to build a picture of what potential scope and requirements are to be considered when developing the solution.

As a [role]

I need to [activity/job]

so that [benefit/gain].

Each user story can be written up on sticky notes and then mapped and ordered so that they can be ranked and prioritised to establish the key requirements.

By working through the user stories we can establish who is dependent on our work and what benefits they need to gain. From this, actions can be established that fulfil the requirements.

Breaking down the scope into jobs is a good way to add context to the solution required: it helps to explore and understand the environment in which it will be used, and therefore be better placed to identify and build suitable solutions that fit the scenario. By establishing the jobs that a user wants to carry out using your solution, options can be established that are more likely to be fit for purpose, since there is an emphasis on delivering benefits and value rather than specific features.

Definition of success

One idea of success can be very different from another, and we need to gain consensus between us and others on the level and quality of work that is to be achieved. It is easy to waste time by doing more than is needed, and cause dissatisfaction from not doing enough.

To help, we can ask simple questions such as, ‘What does success look like?’, ‘How will you know when this has been done?’ These questions can help to establish when your work will be fit for purpose.

Definition of DONE

Each activity you have identified can be completed at various levels, from just completing the essentials through to an ‘all-singing all-dancing’ version. The level needed is defined by those who benefit from your work, and speaking to them about their requirements can be incredibly informative.

• Desirable – ‘would like to haves’ that are beyond the current scope of work.
• Optional – added options that could be included if time/resources allow.
• Necessary – aspects that should be included to reach satisfaction.
• Essential – ‘must have’ components that deliver a workable solution.

Ranking the scope of work into desirable, optional, necessary or essential components helps to identify if and where they should be developed.

Managed variables

Traditional measures and metrics aim to fix the scope, resources and budgets to enable better control, transparency and predictability of an activity or project. Businesses are always looking for ways of taking out cost and adding value and projects are created based on calculating return on investment.

The problem with trying to pin down these variables is they then become constraints and limit solutions by acting as targets and indicators of success. We need to look beyond fixing the investment from the start, and work towards forecasting and managing what we put in against what we get out on a continuous basis. This does not mean that we get rid of budgets or behave as if we have limitless time and resources, but it does mean that the success of the solution is not measured by its ability to come in on time and on budget; rather, whether it has created more value than it has cost.

Often we experience scope creep: as we learn more about the solution that we aim to deliver, we identify additional work or problems that we need to solve, which increases the scope of work. If budgets and resources are fixed at the start of the work and not reviewed, these changes cannot be accounted for, and a project will end up over budget and consume additional resources that have not been calculated for. This is often where an activity that is identified as profitable quickly can become loss making if the costs and returns are not measured regularly.

The application of resources should be flexible to respond to increase or decrease of value created and adjusted accordingly.

By breaking down work into smaller chunks less commitment is needed to secure time and resources, and so the work does not become overly tied into one specific solution. The method enables flexibility and movement by forecasting and reporting continuously to flag quickly when work may be beginning to cost more or less than forecast, and then adjustments made, or decisions taken on whether the solution is still viable.

Rather than try to fix metrics, such as time, cost and quality, we learn to manage them and, continuously, we still have a goal, a potential scope of work and boundaries in terms of resources and costs. By working in sprints and using the concept of minimum viable proposition (more on MVPs later) we can find out early whether our estimations for what we can achieve with the time and resources available are good, or if we have under- or overestimated.

We also can measure the impact and the value of what we are doing early and, since we have spent only a proportion of the time and resources, we can review and revise future spend and focus.

When we scope out a project, we can end up with more options and activities than we have the budget and resources to achieve. Rather than decide what is in and what is out at the beginning, agile allows these decisions to be made continuously, based on the results we achieve along the way.