Developer’s point of view
If you ask developers how detailed the requirements should be, they will tell you that they want to know exactly what clients want to get. And this is good! Vague, high level, general requirements are not going to work for them. Everything has to be measurable so that developers and testers can easily, objectively, assess if a requirement has been fulfilled or not. To give you an example, if client wants to get a clickable button with an image and a label then, in ideal situation, developers would like to get acceptance criteria like:
- size of the image is 16×16 pixels, supported formats: JPG, GIF and PNG
- font size is 12 px and custom styling is not in scope
- label is mandatory and can have between 1 to 20 characters, only alphanumeric characters are allowed
- and so on …
To summarise it – expectation is to get technical details for each and every element.
Client’s point of view
Clients are usually much more high level, they operate on business level. It’s quite rare to hear from a client that they want a “clickable button with an image and a label”. They don’t operate on this level of details, not to mention the size of fonts or number of characters which can be entered as a label.
Much more frequently you will get strategic decisions like:
- IE6 is not a supported browser but still site in IE6 should be functional
- All component should be mobile ready – components should use all capabilities of mobile device and gracefully degrade from smart phones, touch phones to basic phones
- Site should be functional for people who have Java Script turned off
- and so on …
These are all sensible decisions but of course are too general to convert them into acceptance criteria just like that. The devil is in the details…
How to bring these two worlds together?
It’s obvious that there is a huge gap, details-wise, between decisions made by business and development team expectations. Primarily it’s a business analyst, project manager and technical lead job to minimize this gap and get both sides to understand each other. But is it only up to them to do the magic trick? I don’t think so …
To find the common ground, both sides have to step out of their comfort zone. Developers have to start thinking not only how to build a solution but also how to set constraints which will reduce complexity and effort to the minimum and in the same time maximize value for the business. It’s definitely not an easy thing to do. It requires good understanding of client’s needs, deep technical knowledge and experience to assess what solution will work and what will cause more trouble than benefit in future.
Business also have to be involved. Making a few general decisions is not enough for successful project delivery. Business have to collaborate with development team and help them transform requirements into solution.
It’s all about asking right questions
Development team which wants to get more detailed requirements can ask:
- So you want this clickable button with an image … what formats should we support?
- And how many characters you will need for a label?
- How this button should be rendered, are 12 pixels for a label the right size?
Or situation can be like this:
Dear client, we have prepared an example of clickable button for you. We think that in this version everything looks good and all the functional requirements are fulfilled.
- Do you think that image size is correct?
- We think that supporting the most common formats like JPG, GIF and PNG is enough. Do you agree?
- We have limited the length of the label to 20 characters to make sure that button will look good and consistent in all cases. What do you think about that? Is that a sensible limitation? If you want, we can extend this limitation but it will require additional 2 days of work because of something … Do you think that 2 days are worth it?
I think you can see my point here. First set of question is easy but all the thinking is on client’s side. Second set of questions requires preparation and is much harder, especially in more complex cases. I think second case is the way to show that we, as a development team, are adding some value. We are not just sitting and waiting for all the answers to magically appear, we are actively looking for those answers, we are providing technical expertise and this way we are helping our clients to make educated decisions.
What is the final goal?
Projects always have a limited budget (and requirements which are exceeding that budget). Final goal is to maximize return on investment for our clients. Not by working extra hours or running over budget but by
- figuring out which requirements have the most value and focusing on them
- helping to transform general decisions into a solution by providing recommendations and technical consultancy
- keeping things simple, low effort increases customer loyalty
- steering clients out of bells and whistles which are costly
PM can be a bridge between a client and development team but usually PM on his own don’t have enough technical experience to generate recommendations and provide technical consultancy. It’s an objective for entire team.
What are your thoughts on that?