Analysis of user stories is a building block for a successful sprint and a skill that each Agile team needs to develop. My preference is for as much analysis to be completed before development of a user story begins.

We introduced Agile at my current employer about seven years ago, and have had up to six distinct development teams working simultaneously at various times. The approach taken by each to analysis can differ greatly.

My own team has settled for a general principle, do not take a user story into a sprint until it is well defined. That means that:

all assumptions have been validated
there are no outstanding questions left to be answered
there are unambiguous conditions of satisfaction documented, preferably using Behavioural Driven Development (BDD) style Gherkin mark-up
we have documented the classes or files that will be changed, or outlined the design of new classes
we know when this change will be released - at least the current plan
the story must be below a certain size in story points, otherwise it should be broken down into smaller stories
potential regression impacts are documented
all dependencies are documented and verified
the Product Owner or user representative understands and agrees with the assumptions and conditions of satisfaction

This approach has a problem, however, in that we need to do an awful lot of analysis up front in order to meet the above requirements. We call this phase of a development grooming and it does not directly contribute to the team’s velocity - the average number of story points we close per sprint, and is difficult for project managers to build into their projections.

Understanding the requirements can take time, delving into the code, some of which is legacy code and written by people no longer in the company, and agreeing with the business user about what is needed, a process that may require several iterations before everything can be finalised.

A different approach is sometimes used by other teams within our organisation. That is to create an analysis task within the story which should leave enough time to figure everything out. The lead developer will usually estimate how much time is required for this task. The analysis task can cover any or all of the information required to complete the story and allows the story to be brought into a sprint immediately.

This approach means that the story can potentially get to completion sooner, for example in a single sprint, than a similar story in my team, where we would use one sprint to complete the analysis and another to do the work. The elapsed time, where someone is actively working on the story might be the same in both circumstances.

Little or no analysis up front

There can be good reasons for taking work directly into a sprint without a long analysis phase.

You have absolutely clear and unambiguous business requirements.

Under certain circumstances changes can be made obvious by simply stating things clearly. I have found that this is generally not done by users, requiring the experience of a developer or business analyst that knows the system well, and whose familiarity with the system under change will allow them to state the problem in terms that developers can run with almost immediately.

It should be obvious when this sort of user story comes up. During an initial playback of the requirements to the team, all questions are easily answered and the team will probably start talking about the details of implementing the change immediately.

Allowing time for a new developer to get up to speed.

It can sometimes take time to bring the new team member up to speed. It doesn’t matter how much experience they have in the application technology, every system has its own quirks and personality that take time to acclimatise to.

If they can stick with a single change for a few sprints it may let them build up confidence so that they can master that area initially before moving on to another. The task may take longer but the experience gained will help future changes in the same area to go faster.

By handing new developers tasks that have had the analysis done already, they may simply do the work without gaining any deep knowledge of the systems. Through digging around in the code to find their bearings, they gain a more in depth knowledge of the system.

There is a super star developer on the team.

Whether this is someone hired in for a short term contract or an in-house genius, it may be best to let them concentrate all their attention on a single, difficult project. They don’t need to bring the whole team on every step of the path to the solution, indeed this might slow progress down.

You do, however, have to make sure that any technology or code that they introduce is well documented and that they have given some level of training to the rest of the team. Otherwise a key man risk may be introduced.

Developers has a gut feeling that the change is straightforward

A risky one, but sometimes you need to take the lead from the experts on your team. What seems like a complicated, difficult task to one person, may be a simple configuration change to another.

I still believe that if a developer thinks a change is easy, then it should not take them too long to write down some simple instructions. Without having done so the team might be relying on the one developer who knows the system to do the work.

Analysis takes as long as making and testing the change

The bottom line is that spending more time in analysis than you would in making the change is an anti-pattern. Don’t be a slave to the process if you can safely take a short cut.

Risks of not doing analysis before starting

Here are some of the main reasons that I try to resist taking any work into the sprint without detailed analysis.

The change is bigger than at first expected

Developers have a knack of underestimating things and I’m not immune to the problem. One piece of advice I’ve given to the team is to take the estimate and add fifty per cent more time (taken from Essentialism). This is usually pretty good at allocating the right amount of time, taking into account different developers experience.

Another problem is when unknown issues that are hidden from view emerge during development. Perhaps there is a bad code that needs to be re-factored, unit tests added, a bug that will block the delivery, or finding that a re-design of the module is necessary.

Without having done some analysis up front, without validating assumptions, without having named the key classes that are affected and looked at them, you just cannot know. Even then there may still be hidden problems; best to identify as many as possible before starting.

There are unknown dependencies that may block the work

Some projects have dependencies on other teams, often not in the same organisation, such as a software vendor. Project Managers are good at coordinating activity between teams, and are especially useful when a part of the work stream are non-IT.

They can only do their job effectively, however, if each team makes an effort to call out any dependencies that they have. You PM will not thank you if you tell them mid-sprint that you cannot complete a story because so-and-so has not defined the interface for such-and-such.

Had you identified this dependency before starting the work, the PM might have been able to get it done and avoided any delay.

The requirements change considerably

Agile is about responding to change. I recently wrote this article about how to look on change as a good thing. I think that it is OK to expect users to want to course correct the path of a project as they see demonstrations during development.

What this point is about is heading down blind alleys of development where a simple conversation up front with the business user would have resolved any doubt. This is about trying to start off in the right general direction instead of starting and having to do a u-turn.

Conditions of satisfaction do not cover all the scenarios affected

It’s easy to request a change, whether it’s a new control on a web page or a new calculation in a complicated tax algorithm. But it can be hard to think of all the knock on effects of such a change.

Will the new button push something else off the page? How will it affect the look and feel on a small device’s screen? What should it’s default behaviour be? For a calculation, are all the operands available in all cases? What downstream affect will the calculation have? Should it be applied under all circumstances?

It can be difficult to think of all the possible things to check ahead of time. Giving a developer a chance to look and play with the code that will be changed will help to unearth additional scenarios for the conditions of satisfaction.

The regression impact might be underestimated

When making changes to a large existing code base, there is always the risk of changing a part of the system unintentionally. A well designed, modular system might limit this risk, but who among us works without some level of difficult to maintain or change legacy code?

In such circumstances manual testing is going to be required, and that means figuring out what the system does before starting. I said above that developers underestimate the effort involved, but this is not limited to them. Quality Assurance (QA) experts, and indeed humans in general, regularly underestimate how long it will take to complete a task.

If a regression impact is discovered in advance, time can be allowed to develop some automated tests, to plan for manual testing, and to generally manage any unknowns that may crop up.

The conditions of satisfaction change

Agile teams should not worry too much about change; it happens and we deal with it. But if we rush in to development before asking questions, we are more likely to have gotten it wrong up front.

If we regularly demonstrate our changes to users, they will of course ask for tweaks, changes, and additions. But if we did not bottom out a requirement the scale of these changes may be bigger than desired.

Your super star gets sick or pulled onto something else

The problem with that genius on your team is that everyone wants a piece of their time and they are going to be the first to be pulled onto a high priority issue. If you cannot rely on them working on a story then you cannot accept their estimate, which would put another developer under pressure to meet should they have to work on the task.

If the problem you are trying to solve requires that your super star completes their analysis, don’t commit to doing the change until the analysis is done. Otherwise a less experienced developer may be left to try to pick up an impossible task.

Some teams take the most inexperienced team member’s estimate to size tasks. This can be a fair approach, and avoids putting someone under too much pressure. Depending on the ratio of senior to junior developers this may lead to over-estimation.

The key thing for me with Agile is to meet your sprint commitments. Better to arrive early than late.

Assumptions when starting are incorrect

If you assume something, go out and validate it. One member on my team regularly reminds me that “to assume makes an ass out of ‘u’ and me”. Take time to document and validate all assumptions.

It is better to document an assumption than to simply leave the question open. Work can go on with the analysis while an answer is being chased. If the assumed answer to the question is correct there will be no need for change.

Non-functional requirements are not documented

Strive to add non-functional requirements to all user stories. At a minimum, think in terms of responsiveness, security, and capacity. There are many other types of requirement, while not directly affecting the behaviour of the change, are critical for its success. The above link has many different categories that are worth thinking about. Not every category applies to every type of change but the list is worth checking to ensure you haven’t missed anything.

When we don’t give time to these, they can jump up and cause havoc at any time in the future, including after release to production.

Non-functional requirements can become regulatory. The recent GDPR legislation has added consideration of compliance and data retention to every piece of work our company does, both IT and in other departments.

Some other benefits of upfront analysis

Some good reasons for doing all the analysis up front:

we know more accurately when starting a story how long it will take; other teams may carry more stories due to unknowns uncovered
we can identify architectural or security related issues ahead of time and raise with the appropriate person rather than have the question hit mid development
the detailed BDD style conditions of satisfaction can often be quickly converted into Cucumber tests thus giving us automated testing for the changes
developers often dive straight in and write code, but having almost ready BDD tests encourages test driven development, which is a proven way of ensuring that the code will be covered by tests
once we begin work there should be no more delays

Trade off and compromise

As with everything in life you can trade off the cost of things and the benefits they bring. Rather than having a rigid set of rules it is sometimes best to seek compromises in approach. Try to resist taking on change that is incompletely defined, but work with your users and product owner where they simply have to get something done quickly.

Requirements are a changing animal; Agile recommends short sprints specifically to ensure those you started the sprint with do not go too far off course before being reviewed by stakeholders.

Short sprints - two week sprints work well for us - mean that there will not be too great a delay during the analysis phase. The delay will often bring a smoother development.

There are a lot of different types of activities that a development team needs to deal with in the course of a sprint:

work on user stories
completing spikes
team grooming
documenting analysis
user workshops
release planning
handling production issues
getting code released to test environments and maintenance of these environments
sprint meetings such as stand ups, planning, reviews and retrospectives
training and personal development

It can be hard to fit any actual development into a sprint. Team leaders and scrum masters need to try to keep a balance here so that there is enough progress made getting stories done and preparing the next set of stories for development.

The least hiccup in development because of some unknown thing can be highly disruptive and is best avoided by thorough preparation. Although this may feel like you are not getting things done, I find that it pays dividends when the stories come into sprints. The work is done smoothly, often faster than estimated, the test code coverage is higher, and less bugs emerge during testing.

My aim as a team leader is to ensure this high quality of preparation, but I want the responsibility of high quality to rest with the team. If my team sees the benefits of well prepared user stories they are likely to want to take only this level of quality into sprints in the future.

It can be difficult. I still get asked questions about functionality that is already documented in the user story, but that’s OK. A conversation is always welcome to make sure things are worded in such a way that understanding is spread. When we come up with new questions and answers, or a better way to phrase something to remove ambiguity, we improve the user story.

After proving that high quality analysis up front is worth it, the next step is to get the team to work on this high quality preparation themselves. That can take time and patience, training and practice.

How do you know when the analysis is complete? Perhaps when all the known questions are answered. There will always be more questions, more hidden problems or issues, especially when integrating change into large existing systems. We just have to answer them as best we can when they arise, remembering to document what we decide or discover.

Actions

Use the following actions to assess what sort of up-front analysis your team generally does. The aim should be to either find comfort in your approach or to identify existing gaps. There is usually room for improvement.

Pick a recent change that you or your team worked on that did not have all the analysis completed before starting. What were the gaps in the analysis?
Did the work go smoothly? Were there any delays or issues? Did you finish within the time estimated?
Think of another recent development of a similar size but where the analysis was complete. Why was the analysis done better in this scenario? If you cannot find such a case then try to pick something that your team will be working on in the near future and get all the analysis you can done on it before allowing it in a sprint. Then come back and answer question 4.
How did this story go compared to the first? Was there a noticeable difference from delays or issues this time? If the experience was different was the increased analysis a factor? Was the overall effort greater, smaller or the same this time?
Having tried both approaches which was preferred? Is the trade off of spending more time up-front on analysis worth the slight delay on starting the work?
In future try to identify gaps in analysis when developing stories. What impact do the gaps have? How much effort would it have taken to resolve the gap?