This blog is part 2 of ways that poor requirements in Agile can cause projects to fail (if you want to catch up, check out Part 1). Unfortunately, I have seen all these things and learned these lessons the “hard way”. Hopefully, this blog will help you avoid some of these issues. So, without further adieu, here are 10 more ways bad requirements can cause project failure:
1. An overwhelmingly large product backlog
Have your eyes ever glazed over while staring at an Excel spreadsheet with thousands of rows of requirements? I have. It’s not pretty, and it’s very daunting. How can you possibly manage the requirements of that scope? It’s not easy – that’s for sure.
When you have an overwhelming quantity of User Stories, how can you see the big picture of the product? Where do you even begin to start prioritizing and order a Product Backlog such as this? The answer is to start with a Minimal Viable Product (MVP) and create a User Story Map (technique created by Jeff Patton). These are great techniques to help you focus and visualize what you’re trying to accomplish.
2. Dictating the how, rather than the who, what, and why
I call this “solutioning”, and it’s not OK. As a Product Owner or Business Analyst, it’s not your job to tell the developers how to deliver something you want or need. Your job is to define the business problem or opportunity, express the requirements clearly, along with the reason for the requirement.
Including implementation details of “how” the product should be built is an example of “solutioning”. Don’t tell your developers that they must use a dropdown box or a specified technology tool to build the increment. Leave that to them – they’re the experts. If you try to dictate to them, they’ll end up becoming order takers instead of creative problem solvers; you want them to deliver the best solution to the problem.
3. Not following the INVEST acronym
If you haven’t heard of this term before, let me give you a refresher. Bill Wake introduced the INVEST acronym and it stands for:
- Independent – dependent on something else for the story to be successful
- Negotiable – everything in the Product Backlog is negotiable; the team agrees on what to do
- Valuable – the story provides tangible business values based on criteria determined by the Product Owner
- Estimable – there is enough information that the team can size the story using relative estimation
- Small – not too big and not too small; the rule of thumb is that it can be completed within a Sprint
- Testable – must be testable to verify that it meets the Acceptance Criteria and the Definition of Done
This simple set of rules separates good from bad requirements. (The only change I would make is to change “Estimable” to “Sizeable”.)
User Stories that violate any of these rules will inherently be of poorer quality and will cause problems for you and your developers. Ensure you check your stories against these criteria before you consider them ready for development.
4. Not discovering the true business needs, versus expressed wants
This one is a little bit trickier than the rest on this list. This is a novice versus an experienced Business Analyst’s mistake. Most stakeholders don’t really know what they need. They may state that they want something, but that doesn’t mean it necessarily solves the underlying business problem. Your job, if you are a Business Analyst, is to ferret out the real business need, rather than accepting stakeholders’ requests like they’re placing an order at a restaurant.
5. Missing stakeholders
What are the consequences if you miss a stakeholder? You miss some requirements! It’s obvious to me, but I have seen it happen. BAs are pressured to “get stuff done” and aren’t allowed planning time, which is needed to identify and analyze stakeholders. Don’t let this happen to you. Grow a backbone and push back – make the case for why you need time to plan.
One good way to jumpstart this effort is to ask for org charts. I don’t care if you’re a consultant or an employee – you need to understand how a company is organized. This helps you figure out relationships, who has the knowledge, and who is accountable for your project.
6. Conflicting Requirements
This problem of conflicting requirements happens more often with waterfall projects, but it can be a problem on agile projects, too. Conflicts in requirements are always a problem because someone must decide what the correct requirement is. Fortunately, that is where the Product Owner can step in and make the call.
Normally on agile projects, the Product Owner would be quite intimate with the Product Backlog and would immediately recognize requirements conflicts. However, if the Product Owner is delegating some work to someone on the Scrum Team, conflicts can sometimes be missed. The key is to be vigilant and ensure that the Product Owner approves all User Stories before they are ready for development.
7. Too much or not enough documentation
There is a myth that there’s no documentation in Agile, but that’s just not true. There is usually some kind of documentation. But the level to which documentation happens can vary wildly from organization to organization. I like to think of Goldilocks when it comes to this topic, you don’t want it too to be big or too small – you want it to be just right.
Some analysts tend to go overboard on documentation, especially if they came from a traditional background. On the other hand, some people are lazy and want to do as little documentation as possible, meaning that the full picture of the requirements may not be understood. Either one of these extremes is not good when it comes to requirements documentation. You need to have enough to create a shared understanding of what you are building. This would include any artifacts necessary to achieve this goal, such as wireframes, data flow diagrams, data dictionaries, etc.
NOTE: Heavily–regulated companies like finance, healthcare, and insurance are an exception. These types of organizations usually need to have more documentation for auditing.
8. Including design elements too soon
The design aspect of projects is often the most fun part. Unfortunately, introducing these components too soon could sabotage your efforts to get functional requirements nailed down. When you include design too early in a project, stakeholders tend to focus on the aesthetic aspects and not on the functionality.
Early iterations of a product should be lower-fidelity – think whiteboard or wireframes, with placeholders for elements, but no fonts, colors, or graphics. This level of prototype forces the stakeholders to focus on what you want them to, rather than distracting them with the “lipstick” (as my UX/UI guy likes to call it).
9. Obtaining requirements from someone other than the customer
Unfortunately, this is more common in my experience, than not. Typically, a lead stakeholder, or perhaps a Product Owner, is your primary source of requirements. This person tends to “think” they know what the customers want, but they usually don’t. They will spout off a bunch of requirements without any sort of validation that they are useful and/or valuable.
On the other hand, good Product Owners get direct input and feedback from real customers, instead of making assumptions and decisions without empirical evidence. They become the “Voice of the Customer” and use techniques such as empathy mapping, journey mapping, and personas to better understand their customers’ wants and needs.
Bottom line: the closer you can get to the end users or customers of a product, the better off your product will be.
10. Getting requirements details too early
This is yet another common trap I see agile teams run into, especially new ones. I’ll admit that this used to be me before I got comfortable with ambiguity. As a Business Analyst in a waterfall environment, I gathered all the requirements upfront and felt great satisfaction and confidence that I had captured everything. The problem is that by the time development was done, many of the original requirements were no longer valid.
In Agile, the timeliness of getting requirements details is a balancing act. You don’t want to get too far ahead of the Scrum Team, because there is a risk that too much will have changed before the team gets to the requirements. On the flip side, you don’t want to have your developers waiting for you to queue up work for them. As I mentioned in the previous blog, the goal is to get requirements that are “just enough, and just in time”. This means getting the details at the “last responsible moment”. Tricky, right?
Final Thoughts
There are a lot of ways that requirements can go wrong in Agile. I hope that this list will be helpful to you as you write your own requirements. If you missed my first blog in this series, be sure to check out Part 1!
But wait… before you go – are there any other mistakes you have seen made when defining requirements for Agile projects? If so, drop me a line in the comments below!