How do you develop software without acceptance criteria?

Question

How do you collaboratively develop software in a team of 4-5 developers without acceptance criteria, without knowing what the testers will be testing for and with multiple(2-3) people acting as product owner.

All we have is a sketchy 'spec' with some screen shots and a few bullet points.

We've been told that it will be easy so these things are not required.

I'm at a loss on how to proceed.

Additional Info

We have been given a hard deadline.

The customer is internal, we have a product owner in theory but at least 3 people testing the software could fail a work item simply because it doesn't work how they think it should work and there is little to no transparency of what they expect or what they are actually testing for until it has failed.

product owner(s) are not readily available to answer questions or give feedback. There are no regular scheduled meetings or calls with them and feedback can take days.

I can understand that we cannot have a perfect spec but i thought it would be 'normal' to have acceptance criteria for the things we are actually working on in each sprint.

Answer 1

An iterative process will achieve this nicely, without detailed specifications.

Simply create a sketchy prototype, ask for feedback from the customer, make changes based on the feedback, and repeat this process until the application is completed.

Whether the customer is patient enough to do it this way is a different question. Some clients and developers actually prefer this process; since the customer is always hands-on, he'll (eventually) get exactly what he wants.

It should go without saying that you're not going to work a fixed-cost or fixed time contract this way.

Answer 2

If what you're saying is true and the spec is nowhere near good enough for you to even start (and you are being honest in this appraisal), I recommend this aproach:

1. Read the sketches and the "sketchy" spec that you have been given.
2. Write your own spec to a level that is just enough for you to be able to code. You may have to make a ton of guesses.
3. Show your spec to the customer for review. Note the parts that they like, and get more information on the parts where they think you've gotten it wrong.
4. Repeat steps 2 and 3 until you and the customer are in sync.
5. You now have an adequate spec.

If your customer was right when they said "it will be easy," then this exercise should be a piece of cake.

If your customer was wrong and in fact there are all sorts of gotcha's and gaps in the requirements, your draft specification will quickly illustrate the problem and communicate to them that they were wrong (without you needing to point a finger or argue) since it will be right in front of them and obvious. Also, your spec will serve as a great discussion tool for resolving those ambiguities, and will serve as a record of key decisions as you revise it with their feedback.

Answer 3

The product owner handed you a prototype; hand him back better ones (until you are done)

It sounds like you’ve been provided a paper prototype to start off the project. That’s not a terrible beginning. I suggest you communicate back to the business owner in the same language, by providing progressively capable prototypes.

Your prototypes should start with paper, move onto digital mockups, and then get built with “real” technologies.

Treehouse has an excellent guide for this, which concludes:

The wonderful thing about prototyping with a framework is that the prototype often just becomes the real site because the structure and styling are already in place. There’s no need to recreate the site from scratch if it’s going to use the same framework.

You may wish to provide a formal specification as well, especially if you remain worried about getting blamed for a bad result. But you will probably get more feedback from the prototypes.

Meet your deadline

Note that your later efforts will not be classical "prototypes" as all, as they will not be disposable (or parts of them won't be). The last, most capable, iteration you complete before deadline becomes your deliverable.

Your deadline is the best-defined requirement you have. Have something complete and coherent that you can deliver on time.

Collaborate with your testers

If this loose process is a new thing for your company, your testers are probably even more at a loss than you are, and may be looking to you for guidance. You’ve got to get some of their time early in the process. Let their boss know you are trying to help them provide a meaningful test without receiving formal acceptance criteria.

Find out if the testers have anything firm they need to provide, like proof-of-testing documentation, which you can “back into.”

Try Test First Design

Since you have no formal requirements, getting test cases to develop towards would provide some structure.

Get yourself a passing familiarity with Test First Design and/or test driven development and provide guidance to your testers on the process as needed. For a quick project like this, you don’t need to become expert at the process. But using a proven methodology will reflect well on you and your testers.

Stick to standards, especially for UI

You don't have requirements about look and feel, but you do have a deadline. Use somebody else's design work to minimize the work you need to do to create a professional looking artifact.

Choose a standard UI for your site and don’t customize it unless/until directed to. I don’t know what platform you are developing for, but Bootstrap or Google Material Design are two examples.

Communicate, but don’t pester

I would suggest sending one email to the product owner a day. Only send more than that if it’s an emergency.

If you have questions, describe how you will proceed if you don’t receive guidance. For example:

Will the users of this app need to access it with mobile devices? Right now we are assuming this will be a desktop/laptop only system.

Don’t panic

I’ve been involved lots of projects for folks who didn’t know the term “requirement.” Most were successful. Hands-off product owners give you the latitude to build great solutions.

Note, some project owners in these projects were impossible to please and hid behind the “I’m too busy to...” excuse for their incompetence. But most were “delighted” with the end results.

Answer 4

A project is the act of reducing uncertainty until certainty is achieved:

• There's always some degree of uncertainty at the start. Sometimes it's a little ambiguity in the requirements. Sometimes, it's very sketchy ones. You'll you have to work out as part of the job.
• The trick is to iteratively reduce this uncertainty (combining analysis, design & implementation), refining user stories & implementing your system.
• Tests cases/scenarios, and acceptance criteria will have to be clarified the same way. They'll contribute to reduce uncertainty about quality and correctness (among other).
• At the end, a sufficient certainty is reached : the customer gets a tested product that fits his needs and can be used.

That's the principle of progressive elaboration: the requirements, criteria and results will elaborated step by step, as will do the the customer's understanding of his own expectations and requirements through his involvement in the development process.

Is this a problem ?

The sketchier the initial requirements, the higher the uncertainty, and the higher the time necessary to perform the tasks. So it's just a matter of who'll do the additional work and who'll pay for the costs.

The answer of these two questions should be in the contract. Or will be subject of a negotiation. And the customer must accept additional involvement (the main argument will be "garbage in, garbage out", although I'd advise you strongly to present it in a more diplomatic manner ;-) )

Answer 5

"There are no regular scheduled meetings". Well, why don't you start by scheduling regular meetings then? The fact alone that you have multiple product owners guarantees that your project will NOT be easy, as each of those people WILL have conflicting requirements that MUST be discussed in person with all the stakeholders present.

Additionally, I really, really, really recommend you keep a detailed decision log. At the very minimum you write down everything that someone has decided, with the date and a list of people who were present when the decision was made. Even better if you can write down WHY something was decided the way it was. It doesn't matter if it's a file on your PC, a page in your intranet wiki, or a notebook on your desk. The log protects you and the project: when a tester says some item "fails", you can point out that it was decided that way with these people, and it's not your problem but between them and the testers. If this leads to the specs being changed then fine, but at this point they cannot expect to meet any deadline they had in mind -- or they must cut the scope somewhere else.

Answer 6

A project without clear requirements, loose leadership, no definition of done (DoD), no one willing to be accountable to making sure that you have the information you need to do your job in a timely fashion and meet their deadline is a recipe for project failure.

Iterative development isn't a bad suggestion, but it requires close cooperation between the product owners and the developers. Try to get someone on the hook by saying, "We know we are going to have questions. Who can be regularly available to make sure those get answered so the project delivery isn't delayed?" Schedule regular times with someone to review progress and remove impediments. If they don't show, or refuse, then follow-up with polite written correspondence and document delays or non-responses. If the product owners can't be available, ask them to provide a representative that can be.

Also, another hallmark of iterative development is that a change in the requirements necessitates a change in the timeline. You can't commit to meeting a deadline if you can't develop a timeline, and you can't develop a timeline if you don't have a good idea of what needs to be done. Instead of dogmatically asking for a spec, review the current spec, document any questions that you or the team have regarding how it is supposed to function, schedule time with the product owners to discuss it, and document the answers. When you are done, you'll have your specifications based on their decisions, which you can then get the product owners to agree to (in writing). The purpose of a spec is to remove ambiguity and create a DoD, which is exactly what a Q&A session could provide. If there is opposition to a spec, don't call it a spec.

Don't believe anyone when they tell you it will be easy. Sometimes it really is as simple as it sounds, and I might believe this if (and only if) I know the product owners well enough to fully trust that the requirements really are as simple as they say they are, and the specs I have been provided are self-explanatory (if not, I schedule a Q&A session and document it). I have been in too many situations where easy from an operations standpoint is incredibly difficult from a development standpoint, or you think you are totally done and you hear the words of despair ("Oh, by the way, we forgot about..."). Example... "All you have to do is read these PDF files out of a document repository," which, during acceptance testing turns into, "Oh, we forgot that some of these were read in sideways in a completely inconsistent manner, and some have the wrong page size defined, and some need these three pages appended, and we need them all to display the same. That is really easy to fix, right?".

The point is, it might be really easy, and a quick meeting could confirm that, allowing you to document all of the assumptions and get confirmation that they are accurate and correct. I do recommend standing up in order to remove impediments you have to writing working code that meets their expectations, because regardless as to whether you step on toes, someone will probably be unhappy in the end anyways. If you are persistent about getting questions answered and irritate someone, they will forget about it when you deliver a great product on time that meets requirements. If you fail to get clarification and don't deliver, no one will remember that they told you not to bug them.

Answer 7

Without a spec, you have teamwork. Go Agile.

Sit down with the PO and flesh out a/some small starting story/ies. "We're going to deliver just this screen, with just this button that goes 'bing!'". Settle on some ACs. Deliver the story. Demonstrate the story. Turns out the buttons should be red. Raise a bug or a new story. Deliver the buttons that go bong and bang. And so on.

Collaboratively specify and deliver small vertical slices that are frequently demonstrated.

If the customer won't work with you in this way, look for a way out.

Answer 8

You need a detailed, verifiable spec before you can start writing code. That's a fact, and there is no getting around it.

If nobody else is willing to write that spec, then the developers have to write it. So you get an incomplete spec. You turn it into a complete spec (which means "this is what I'm going to implement unless someone else tells me not to"). You hand that spec to the stakeholders and give them a chance to modify the spec. Only a chance to modify the spec - not unspeccing it for example by saying "I don't like it this way". At that point, it's your spec, or they can supply a different spec, but not remove the spec.

It may be a good idea to get a quick review from your colleagues who might improve the spec. But anyway, you have a spec, you write the code accordingly, the testers test accordingly. And you have done your job: You had a spec and implemented it. If the spec is not what the customer wants, that's straight the responsibility of the product owner or the customer who couldn't be bothered to write a good spec.

Answer 9

I have spend several jobs doing projects just as you have outlined. As long as the PO knows what design decisions you are making and why you have to make them, you should be fine. If, on the other hand, they do not understand the design decisions, then you need to press them for at least a written user acceptance test document.