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


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


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

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


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

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

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

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

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


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

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

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

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

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


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


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