38

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

I fail to see how you can carry out requirements engineering activities effectively without the involvement of developers. A business analyst or product manager may be very good at working with stakeholders to understand their needs and how to close the gap between the current state of the product and the stakeholder need. However, requirements also need to ...


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

Everyone in a development team should take responsibility for and be involved in requirements gathering to some extent, otherwise you have barriers to effective teamwork. "The best architectures, requirements, and designs emerge from self-organizing teams" (agilemanifesto.org) Development teams follow that dictum by not limiting people to specific ...


11

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

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


9

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


9

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


9

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


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

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

Developer here. I have seen projects fail because a functional requirement was impossible to implement. I'll tell you a tale where I was involved. We were working with a piece of hardware that allowed you to capture TV signal. It came with its own software that allowed you to tune in to channels and watch TV in your computer. This was before digital TV was ...


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

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

There is a lot you can do that ensures that the code does what it's supposed to do, but aside from trusting the people developing it (including their reviewers) there is basically no way to make sure it does not do more. But it comes down to that trust in any other job, too. At some level, you need to trust the people. If you cannot, get others that you ...


7

TL;DR Your company has not implemented SAFe; they have implemented Buzzword Management™. In this case, the interplay between roles has been applied incorrectly. Core responsibility for requirements management is a product ownership function, but the development team has a collaborative role to play, too. The Scrum Master's role is to be the process referee ...


7

You cannot totally eliminate dependencies. Some story will depend on another, some feature will need another feature to be built first, some new feature will be desired only after you see and interact with some already built feature, etc. That's just the nature of things. So the "Independent" in INVEST isn't about eliminating dependencies, it is about ...


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

TL;DR I think the question of "requirements gathering" is based on a misunderstanding of the agile principles involved, and especially of how user stories are created and how the details of a story should be fleshed out into an implementation. Simply re-framing everyone's expectations properly may help a great deal. While it may not be feasible to have 10 ...


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


6

With respect to @mamoo answer: For sure, the best is to clarify the requirements. Due to the fact that you don't have access to the customer, the internal stakeholder should be your first choice. Unfortunately, it might be difficult to find a timeslot for some stakeholder (e.g. management) to participate in a workshop or in other technical work. Try to ...


6

Mathias' answer is solid. I personally would not go to a full Scrum for this, based on it being a single person project and work in progress is the more critical thing going on here. So I'd stick with a straight Kanban workflow with careful watch on your WIP limits for active work. Essentially you need to tier your backlog. Like a funnel you get deeper and ...


6

Project Objectives are typically higher level than individual Stakeholder Requirements. They usually come first, created up-front in the Project Initiation phase before you've delved in to individual Stakeholder Requirements. Stakeholder Requirements are lower level and more specific that Project Objectives. They'll carefully define the needs of the various ...


6

Using a Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD) approach means that the code is self documenting. So introducing functionality beyond the original requirements would be obvious to anyone who paid attention to the code base. What constitutes 'extra code' is a much more difficult question. It is quite possible that code ...


6

Two things come to mind. First, if you can't trace the need to a stakeholder impacted by the system, is it actually a requirement? Unnecessary features and gold-plating is a waste, in the Lean sense. However, just because you can't trace it to a known user class doesn't mean it's not valid - it could be hard to express some non-functional requirements, ...


6

The only time the Product Owner would be named in a user story is if you are building a product that is designed for Product Owners. I need to write some requirements affecting directly to the product but not exactly to any user, but necessary to achieve the product. Will users of the product really see no value at all from the requirement? If that is true,...


5

I think the problem is that you haven't broken down the story. When you write a story try to break your high level requirements into smallest level possible. Example in the case which you have mentioned: As a customer, I see Order Confirmation screen, where I can review items ordered, amount total, tax information. I click on Pay Now button to be ...


5

Yes, you do because otherwise nobody will be able to track the changes of the system, and know how your system is supposed to work. Make sure that you mark the change section in the history of the document.


5

A common issue. There are a few approaches, but this is the one I use: Each change, or set of changes is captured in a new Change Request document. The CR document must capture the new requirements in as much detail as is required to a) approve them b) perform the functional requirements analysis c) do a reasonable estimate of the effort required to deploy ...


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