34

Each organization and author has a different definition for these terms. In this article, Mike Cohn provides his definition of User Stories, Epics and Themes: A user story is simply something a user wants. User stories are more than just text written on an index card but for our purposes here, just think of user story as a bit of text saying ...


21

Let's start with obvious observation: the moment that we know least about a project is at its very beginning. Unfortunately, for fixed-priced projects it is also a moment when we usually requested to say how much it's going to cost, thus to estimate. In such situation I would focus more on improving estimate quality than on choosing this or that estimation ...


13

Fixed price contracts and ambiguous scope do not belong together ...ever. You cannot go down the path of even saying clearly what you will do because no one knows what needs to be done. You cannot plan to handle it with change requests because a CR is a change to scope...and you don't have any scope. This is a time and materials contract. This is not ...


13

Exporting to Excel is a solution, not a requirement. You need to go back to the owners and get them to detail their functional requirements for the data. Once done, then hand it over to the developers and let them propose a solution. It may end up being Excel because, as you wrote, it's already there, or it might be another solution that meets the ...


12

If the requirements are loosely defined then there should be regular and frequent delivery of working software to the client. Wireframes and prototype may help but not that much as compared to functional system. By working software I dont mean that build everything but initially focus on those pieces that will provide most value to the client. Let the client ...


11

No guarantees on this one, but here is what I would try: Either they are not understanding your documents or they are not doing the work and using the documents as a scapegoat. It is a little extreme but ask for a restatement of your documents along with their anticipated approach. Get this by the next day as a precursor to them commencing work on the ...


10

First, consider yourself lucky that you haven't yet signed the formal agreement. It's a lot easier to bring up bad news to a client early on than it is at the end, when the client is ready to take delivery. At such an early stage, you shouldn't need to just eat the cost. At this point the client hasn't lost anything. If they want to get the project done ...


10

Missing or incomplete requirements is one of about 1,000,000,000 random variables that will impact you during the course of a complex project, both favorable and unfavorably affecting your cost and schedule estimates. Many of these variables, you won't even see and, thus, will not have any opportunity to ask who is at fault on this exchange. This is ...


10

I totally agree with Michael and Mark. Both nailed the problem with the ask for a restatement of your documents along with their anticipated approach. They're clearly not understanding the requirements. The problem is... are they trying to understand beforehand? If they're not analysing the requirements and jumping straight to the dev, they'll have a hard ...


10

I respectfully disagree with @DavidEspina. I don't think his answer is fundamentally wrong, but it doesn't match my answer. During project initiation (or in some contract work, prior to project initiation) you determine the scope of work. This is the box inside which all requirements must fit. The project sponsor and project management team must strongly ...


10

As a principle, whether having an Excel is "worth" (business-wise) or not isn't up to the development team to decide. They have to be able to tell whether it's feasible, and objectively tell what are the pros and cons (i.e. it won't work when you have more than 1.000.000 rows of data), they can also advise the client on whether this really solves their ...


9

Assuming that the decisions that you want made are valid (i.e. you aren't overwhelming your customer with details that are really your responsibility to decide on), the problem seems to be that your customer, or maybe just your point of contact, is not engaged with the project. You need to address this root cause or you will spend a lot more time and effort ...


8

Change the format. Traditional functional requirements are pretty flawed and have decades of focusing on the "what" and not the "why" or the "who." User Stories and User Persona based requirements focus on the "who" and the "why." While agile is the most obvious user of this today, it's not a new concept. I first learned about this concept through a ...


8

Business Requirements (BR) and Use Cases (UC) are two different poles of the software development cycle (SDLC). You have to consider both, but apply them at different times of the SDLC. Take a look on this diagram (taken from here): Both documents come from the customer's perspective, but apply differently: BR essentially define primary objectives (hence ...


8

Marketing materials like this is more of a 'you know when you see it.' The development of this type of deliverable is a back and forth process. You elicit what you can, you design and build, you test it, you go back and make changes. I would challenge you in the waste of time and money opinion. Doing it a more controlled way may save time and money, but ...


8

Product Specifications vs. Project Scope One assumes that you're not looking for dictionary definitions. We have Merriam-Webster and Wikipedia for that. For practical differences, I would suggest the following perspective: Requirements Requirements are the things your project needs built, and specifications are the instructions for what the things you want ...


8

I would recommend to apply a Scrum project approach here. You should define your minimum viable product. You create a larger backlog which contains all project ideas (or user stories). You organise then sprints where you pick the backlog items on which you want to work on next. Trying to track all the goals at the same time will not work. You need to ...


8

Everything in your question suggests that you are exploring a new problem, not simply creating something you already know exactly how to build. Because waterfall asks you to create your design completely before you start building it, using waterfall would be inherently problematic. In Agile, and Scrum specifically, the goal of making a product increment and ...


7

Conflicting or inconsistent requirements are not just part of an IT project but span across all types of projects. You can be certain, no matter how hard you try not to, that you will create a requirements baseline with a host of inconsistent or conflicting set of requirements. On top of that, the solution derived to meet a requirement could break another ...


7

Scrum Does Not Prescribe Development Practices Scrum is not a development methodology; it's a project management methodology. The Scrum process holds no specific answers for you from a requirements standpoint. Scrum Provides a Framework for Your Questions However, Scrum holds that the questions you are asking are part of the self-organizing that your team ...


7

You certainly have a problem. Ultimately the problem is yours, even if the team is composed of total slackers. You're accountable for delivering on time; the team is accountable only to you. I'm not sure that offshore/onshore is relevant; I'm not sure that many of the details above are relevant (except that we would have asked if you hadn't supplied them.)...


7

Problem with described User Stories is that such stories cannot be finished during several sprints and will be dragging from sprint to sprint. You need to break down your stories further using the INVEST model. Write your stories in a way so that each one is self contained and there is no or minimal dependency on other factors. So your story can be re-...


7

Of course you may! Scrum doesn't prescribe what concrete representation of requirements you should use. There is no such term as "user story" in Scrum Guide at all. Scrum Guide operate "Product Backlog Item" instead. Scrum Guide imposes three constraints to well defined (or "refined" in Scrum terminology) PBI: It should be clear to all Scrum Team members. ...


7

In Scrum (where User Stories also exist as part of Product Backlog), it is common to see Security, Availability, Speed of response and other non-functional requirements as part of definition of "Done". This kind of coincides with your notion: I.e. if developer implements some User Story, he should already implement it with good security quality. This ...


7

Never... :) By leaving the scrum team out of the conversation, you are just moving back into the pitfalls of waterfall requirements. When features are written in a vacuum, then you either end up with a feature that rarely meets the product managers or many back and forth documents as PM and Eng "negotiate" the feature. You're also missing out on an ...


6

If you have to estimate without requirements, you need to be very clear in stating precisely what you will do for the fixed cost payment you will request. So rather than accepting "the job" (which is some loosey-goosey handwaving specification), you will list specific deliverables that you can accomplish. Make it very clear that the deliverables will only ...


6

Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, ...


6

I agree with Doug (+1) that's on customer to decide how important the project is to himself. If he doesn't dedicate enough time to the project, he may not consider it as important as you may think the project is. It doesn't mean, however, that your team will stand still waiting for them to discuss the open points. As you mentioned, I'd go for the first ...


6

Here are some pitfalls I've seen with the MoSCoW model. Managers are worried that their requirements will fall into "should" or "could", and won't get done, so they make up reasons why their requirement is a "must". This ends up delaying business-critical functionality. (This is usually caused by, or exacerbated by, bad KPIs at an organizational level. I'm ...


6

Agile provides 3 opportunities to catch this error prior to production The dependency should have been captured in the acceptance criteria: When story B is written, it should have been linked back to story A. And an acceptance criteria should have been written to capture that. Unit test should break: While not all Agile teams may be writing unit tests, ...


Only top voted, non community-wiki answers of a minimum length are eligible