68

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.

Improve this question
15
  • 36
    I'd say, develop it however you want. As long as you feel comfortable going into a meeting and demonstrating how your product matches the sketchy "spec" and screenshots, I think you're ok. Of course, you could always ask the creator of the spec for further details...
    – FrustratedWithFormsDesigner
    Jan 9, 2017 at 20:47
  • 11
    Basically this is automonous development or "Cowboy Coding". Developers fill in the details. Developers have majority control. Basically you will never have formal requirements. Develop, demo for stackholder(s), gather feedback, rinse and repeat.
    – Jon Raynor
    Jan 9, 2017 at 21:18
  • 11
    Does the product owner understand this is an excellent way to ensure costs and time spiral higher and higher? Non-computer scientists, frequently do not understand the importance of well written clear specifications. For example, the U.S. government frequently runs into similar issues, when they change expectations for new military hardware. This is one of several reasons why military hardware is frequently overbudget and behind schedule. joelonsoftware.com/2000/10/02/…
    – nickalh
    Jan 10, 2017 at 2:14
  • 35
    "We've been told that it will be easy so these things are not required. ... We have been given a hard deadline. ... 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." You have my sympathy. These are hallmarks of, "No idea how writing software works. At all."
    – jpmc26
    Jan 10, 2017 at 6:09
  • 15
    You have been set up for failure. This is the kind of thing that needs to be escalated to management. If you didn't have the hard deadline, you could iterate until you succeeded. If the stakeholders were available for feedback, you could iterate fast enough to (possibly) hit the deadline. Ditto for actually having a reasonably detailed spec. But something has to give. This is the part where you ask your boss very nicely to pull your @$$ out of the fire.
    – Jared Smith
    Jan 10, 2017 at 13:27

9 Answers 9

Reset to default
127

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.

Improve this answer
13
  • 117
    One should add: "just make sure you are paid per hour", and not "paid only when the client is running out of ideas what is missing".
    – Doc Brown
    Jan 9, 2017 at 21:46
  • 23
    Also make sure to document what the customer thinks, too, so it's at least captured in notes somewhere. It might not be formal acceptance criteria but it's plenty relevant to have when you're trying to actually do the next steps..
    – enderland
    Jan 10, 2017 at 0:50
  • 4
    @Doc Brown: OP edited to add "The customer is internal" - so payment by the hour is hopefully not an issue.
    – sleske
    Jan 10, 2017 at 8:16
  • 8
    +1 Have followed this process for many internal projects and found it works really well and is, moreover, an overall time-saver. One tip is to keep the iterations short: a week or two.
    – Bob Tway
    Jan 10, 2017 at 14:55
  • 15
    My experience is that this works well when the reason for the lack of formal acceptance criteria is that nobody is yet sure what they really want. Prototypes help them form opinions, and you accept that you've got a large uncertain task to hand. But it works fairly badly when the reason is that the stakeholders aren't finding time to think/talk/write about what they want, or where stakeholders have conflicting requirements that for political reasons they don't feel they can state explicitly. Then a prototype just kicks the can down the road, and nothing improves until you find a stout stick.
    – Steve Jessop
    Jan 10, 2017 at 17:13
55

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.

Improve this answer
4
  • 28
    Sometimes you can trick the customer by calling your spec a "schedule of work" (which their non-programmer brains accept as a friendly and useful thing for a project to have) instead of a "spec" (which, in the case of customers like this who are hostile to all basic principles of engagement in the development process, their non-programmer brains think of as a tedious piece of pedantic paperwork that programmers make them do for no good reason).
    – Steve Jessop
    Jan 10, 2017 at 12:42
  • On second point, i would suggest you should only write the technical spec for the developer. Otherwise, the developer would be unable to start his work. This way, you can collaborate with the business team in parallel about the nature of work that is going to be developed. This way both the development and the business team gets synced with each other on the requirements.
    – Karan
    Jan 10, 2017 at 13:14
  • 3
    your draft specification will quickly illustrate the problem and communicate to them that they were wrong (....) since it will be right in front of them and obvious - I'd like to point out that clients who realise how obvious all this is are exactly the clients with whom you'll never have that problem to begin with. Or, to put it more succintly: the solution implies the non-existence of the problem (which is a paradox I recognize more and more often in all areas of life)...
    – Radu Murzea
    Jan 11, 2017 at 15:57
  • 1
    There are some folks who will never "get it," but in my experience it often helps to show them an example of the level of detail you need, and show them the sort of "wrong" decisions that you can make when the requirements are ambiguous.
    – John Wu
    Jan 11, 2017 at 17:02
18

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.

Improve this answer
0
10

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 ;-) )

Improve this answer
1
  • 1
    I love the first sentence. The bookend to that is that the customer might: 1) not be certain what they want, 2) change their mind as they go, 3) want something unachievable. But if this is actually a simple project, then it has a good chance of succeeding.
    – user251748
    Jan 10, 2017 at 14:35
8

"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.

Improve this answer
8

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.

Improve this answer
3

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.

Improve this answer
-1

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.

Improve this answer
5
  • 6
    "You need a detailed, verifiable spec before you can start writing code. That's a fact, and there is no getting around it. " My coworkers and I have done that on many projects and we've had many successes and very few failures. Your claim isn't absolute.
    – whatsisname
    Jan 10, 2017 at 22:34
  • 1
    @whatsisname agreed. I too have written code this way. This happens when the task has an exploratory aspect to it. Now there are drawbacks to coding without a spec, but sometimes they are more acceptable than saying you can't accomplish a goal.
    – Cort Ammon
    Jan 11, 2017 at 0:36
  • 1
    @whatsisname, the phrasing could be improved, but the basic truth is that you cannot fulfill a request without understanding what it is. If I just say, "Write me a program in Java," it is impossible for you to write that program. You can make up your own idea of what the program should do—in other words, invent your own goal, and then fulfill it—but it is a pure impossibility to achieve a goal that has never been stated by anyone including you. This applies to any requests, big or small; the needs and wants must be understood before you can do, produce and/or present them.
    – Wildcard
    Jan 11, 2017 at 6:07
  • That said...the level of detail that a request actually requires in order to be understood and fulfilled can be drastically overestimated. It can also be underestimated. The only solution to this is communication.
    – Wildcard
    Jan 11, 2017 at 6:08
  • @Wildcard: yeah I think the phrasing could be much approved. What you are trying to say is reminiscent of Zeno's paradox but less compelling.
    – whatsisname
    Jan 11, 2017 at 17:47
-1

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.