Marek Blotny's Blog

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:

1. So you want this clickable button with an image … what formats should we support?
2. And how many characters you will need for a label?
3. 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.

1. Do you think that image size is correct?
2. We think that supporting the most common formats like JPG, GIF and PNG is enough. Do you agree?
3. 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?

Adopting agile methodologies doesn’t guarantee success of each and every project. Sometimes you can have absolutely great team, skilled and well motivated people, flawless development process and yet project can be a total disaster.

How can that be? Prerequisite for all projects is a product backlog (requirements specification). If user stories (requirements) are vague and scope is blurry then probably this is classic garbage in, garbage out scenario. In such scenario a single team with no external dependencies and good cooperation with a client has a slim chance to succeed. But in projects, with number of different teams involved, there is absolutely no way to produce something else then garbage.

How to avoid garbage in, garbage out scenario? Before giving a green light for a project ask yourself a few questions:

1. Are requirements documented? – you don’t need each and every small detail, but high-level user stories are a must.
2. Are requirements clear and explicit? – requirements should be put in simple words without any ‘marketing talk’ but also without technical details.
3. Is scope for your team well defined? – this is about clear responsibility boundaries. You want to know what your team is supposed to do; also you want to know which team should help you with your external dependencies.
4. Do you understand goals for a project? – what is a business justification for this project? What client wants to achieve?
5. Do you understand the most fundamental user stories (use cases) of a system? – do you understand how system should work? How complex the features are? How many internal/external systems will be involved in building each feature? For each feature – what are the responsibilities for your team?
6. Do you have access to the product owner/client/stakeholders to be able to ask questions? – For sure you will have some questions, you will find some edge cases therefore you want to have access to someone who can make some decisions and conclusively answer questions.

If answer to at least one of the above questions is ‘no’ then you have to be careful because quality of project’s specification is substandard. Of course you still may want to take a chance but be aware – it’s a risky game.