New answers tagged

0

Gathering requirements in an Agile framework and no-one has mentioned User Stories? A user story is essentially a high-level definition of what the software should be capable of doing. Typically, any feedback or request that comes from the business or end-user can be written as a user story. ... You can think of acceptance criteria as the functional ...


3

Capturing requirements is an essential part of any (successful) software project. But writing a requirements specification isn't. A documentation-centric approach can end up like a game of Chinese Whispers: a subject matter expert voices a requirement, an analyst writes it down, a dev tries to write something that meet's the analyst's description, the end ...


0

Here's how we did it. We talked to the owners. We talked to the Managers. We talked to the users doing the work. What we found by sitting down at a user's desk and watching (and asking questions) was amazingly useful. The managers knew which users we should sit down with. We discovered that some parts of the system worked very well indeed, and we could ...


13

Agile doesn't change the need for functional requirements, but it does generally change how you gather them. The non-agile way is for someone to go through a long process then give you some sort of document containing all the requirements for the system. The agile way to gather requirements is to work together to specify the requirements for a small ...


19

Whether or not lacking functional requirements is agile, it is a recipe for disaster. You cannot rebuild a system when you do not know how that system works. You need to tell the business owner that you have no idea how the old system works. Your best option is to work with your business owner or a few experienced users to understand the business processes ...


2

You should not take the INVEST principles as black and white. Especially the "Independent from each other" cannot be true for all the stories and certainly not without breaking the other principles. User stories should be independent from each other, because dependencies can lead to problems and delays, but not all dependencies are equally bad. The least ...


1

https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done clearly states that the DoD is defined by the development team. If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product. If there are multiple Scrum Teams ...


1

There are a couple of different ways of handling this. If the concept of "super admin" and "admin" both exist when implementing the work for the first time, then you should make it clear that a "super admin" is a superset of "admin" users. If you have user classes or personas, this would be captured there. You can also capture acceptance criteria on the ...


1

You should talk about this in your retrospective (or whatever regular process your team does to inspect and adapt), and come up with a solution that works for you. You already aren't doing "pure" scrum because you are doing design work in your standups. That's perfectly okay. Keep adjusting your process based on feedback. The way I see it, you're really ...


11

It sounds like you are at the extreme thresholds of Scrum. According to the Scrum Guide, a Development Team that has fewer than three members has less interaction or doesn't need as much interaction as a slightly larger team. Therefore, you may not see benefits from using the Scrum framework in a way that slightly larger teams would. It also sounds like the ...


Top 50 recent answers are included