For most teams I work with, especially those in big companies, scope is something passed to them from a higher instance. Many teams think that it is impossible to argue about business goals when they maintain only a piece of a large system. Even in such situations, understanding what the business users are trying to achieve can significantly help you focus the project on things that really matter.

Here are some tips for effectively collaborating on the project scope when you don’t have a high-level control of the project.

Ask How Something Would Be Useful

Stuart Ervine worked on a back-office application for a large bank that allowed business users to manage their counter-party relationships in a tree-like hierarchy. That is a perfect example of a small piece of a large system. But even then, they were able to push back on tasks and get to the real requirements.

His team got the task to improve the performance of the hierarchy, which sounds like a genuine business requirement with a clear benefit. But the team could not replicate any performance issues so any serious improvements would require infrastructural changes.

They asked the users to tell them how improved performance would be useful. It turned out that the business users were performing a complex calculation manually by going through the hierarchy and adding account balances. They had to open and close tree branches in the user interface for a large number of counterparties and add account balances for this calculation, which was a slow and error-prone process.

Instead of improving the performance of the hierarchy, the team automated that calculation for the business users. This made the calculation almost instant and significantly reduced the possibility of errors. This solution delivered better results cheaper than the one originally requested.

Instead of a technical feature specification, we should ask for a high-level example of how a feature would be useful. This will point us toward the real problem that needs to be solved.

I advise asking why and repeating the question until we reach the money. I now think that asking for an example of how a feature will be useful is a much better way to get to the same result. Asking why something is needed can sound like a challenge and might put the other person in a defensive position, especially in larger organizations. Asking how something would be useful opens up a discussion without challenging anyone’s authority.

Ask for an Alternative Solution

In addition to asking for an example of how something would be useful, Christian Hassa advises discussing an alternative solution to get to the real business goals. Hassa explains:

Sometimes people still struggle with explaining what the value of a given feature would be (even when asking them for an example). As a further step, I ask them to give an example and say what they would need to do differently (work around) if the system would not provide this feature. Usually this helps them then to express the value of a given feature.

Asking for an alternative solution is a good strategy to discover additional options from a business perspective.

Asking for alternative solutions can make whoever is asking for a feature think twice about whether the proposed solution is really the best one. It should also open up a discussion on alternatives that the delivery team might suggest.

Don’t Look Only at the Lowest Level

Many teams now break down backlog items to a very low level, influenced by the need to slim down delivery items so that they can fit into an iteration. While this helps with process flow, it might cause the team to lose sight of the big picture.

Specification by Example as a process works both for high-level and lower-level stories. Once we have a high level example of how something would be useful, we can capture that example as a high-level specification and an acceptance test, which allows us to objectively measure whether we have delivered a feature.

Ismo Aro worked on a project at Nokia Siemens Networks where they were hurt by not having higher-level specifications. He says:

User stories have to fit into the sprint. When there is a bunch of those that are done, they are tested in isolation. The larger user story isn’t actually tested. When the user stories are small grained, you cannot really tell from the backlog whether things are really done.

Splitting larger user stories into smaller ones that can be delivered individually is a very good practice. Looking at higher-level stories is still needed to know when we are done. Instead of a flat linear backlog, we need a hierarchical backlog to look at both levels.

Lower-level specifications and tests will tell us that we have delivered the correct logic in parts; a higher level acceptance test will tell us that all those parts talk together as expected.

Make Sure Teams Deliver Complete Features

When: Large Multi-site Projects
Wes Williams worked on a project at Sabre where they delayed building the user interface and says that this caused a lot of rework:

The acceptance tests were written against a domain [layer], before our customer could see the GUI. The UI was delayed for about four months. The customer thought completely differently about the application when they saw the UI. When we started writing tests for the UI, they had much more in them than the ones written for the domain [layer]. So the domain code had to be changed, but the customer assumed that that part was done. They had their test there, they drove it, and it was passing—they assumed it was done.

Wes Williams blamed the division of work for the problem. Teams delivered components of the system (in this case, the domain layer and the user interface), which made it hard to divide the work so that they could discuss the expected output for each team with their customers. They reorganized work into teams that could deliver complete features. Williams says:

It took us about six months to put it to feature teams. This made a big difference especially in the sense that it removed some duplication, a lot of repeating, and a lot of rework. Fortunately, we already had a lot of tests that helped us do this. We did have to go back and add features but it was mostly adding—not changing.

When teams deliver features end to end, they can get engaged with business users much better in designing the scope and determining what actually needs to be built, simply because they can discuss full features with the users.

Even without high-level control of project scope, teams can still influence what gets built by:

• Actively challenging requirements.
• Understanding the real business goals.
• Understanding who needs what functionality and why.

The result will not be as good as when the right scope is derived from business goals from the start. But this approach prevents unnecessary rework later in the process and ensures that the business users get what they really need.

Further Information

There is a lot of innovation in this field at the moment. To learn more about cutting edge techniques for deriving scope from goals and mapping out the relationship between them, look for resources on feature injection, effect maps, and user story mapping.

Remember:

• When you get requirements as tasks, push back and understand the real problem, then collaboratively design the solution.
• Think about the business goal of a milestone and the stakeholders who can contribute or be affected by that milestone to derive the appropriate scope.
• If you can’t avoid getting tasks, ask for high-level examples of how they would be useful to understand who needs them and why, and then design the solution.
• Specify using examples and define acceptance criteria on both the higher (feature) and lower (story) levels.
• Start with the outputs of a system to get the business users more engaged.
• Reorganize component teams into teams that can deliver complete features.
• Investigate emerging techniques including Feature Injection, User Story Mapping, and Effect Maps to derive scope from goals effectively.

 

---

For more information about Gojko Adzic's Specification by Example, including source code, sample chapters, online author forum, and other resources, visit the publisher's page at http://www.manning.com/adzic/.