The Stack Overflow podcast is back! Listen to an interview with our new CEO.
8

Given that, what are the alternatives to gather requirements from large specification files with Scrum? I'm afraid that there isn't any. It is either the Product Owner, the Scrum Team, or them together. Another option might be to hire an expert how can help out with the processing of the documentation. Should the PM take care of it with a specification ...


7

Responsibilities for Specifications The customer is ultimately responsible for specifying requirements. Whether your company has a business analyst or project manager is irrelevant to identifying the responsible party. A business analyst is generally a liaison between the development team and the client, and is responsible for working with a client to ...


7

Stories should always be defined in business terms. Why does there need to be web integration? Who is it for? What exactly does it need to accomplish? If it is not directly-related to a business requirement (unlikely for web integration, but theoretically possible), then it should instead be a developer task, and thus it should be defined by a developer. ...


6

How do we capture enough details so that in a month or so, when someone in those discussions comes back and their memory of it was different from ours, we don't get into a debate/discussion over whether it is a new story or a bug because we didn't implement right in the first place? You and the customer are currently trapped in waterfall thinking. You're ...


6

TL;DR You should not be defining tasks for technical people. Instead, you should describe a value proposition and some testable acceptance criteria, and then turn your technical experts loose to find a solution that delivers the defined value you're looking for. User Stories Describe Value User stories are a good vehicle for defining value. Using the ...


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


4

You don't need a project manager to run this project. In fact, unless heavily empowered all a project manager is going to do is give the headache to someone else. What you need is to have a "product owner" or "chief product owner" for the overall Web Site. A product owner's job is to the "final call" on requirements. This includes prioritization, ...


3

Many agile projects don't product a software requirements specification in the sense of a document that lists a bunch of "shall" statements along with some assumptions and dependencies, like what is described in ISO/IEC/IEEE 29148 or DI-IPSC-81433A. That doesn't mean such a document can't be produced, though. Often, agile projects will capture requirements ...


3

TL;DR Your assumption that you need to track changes across multiple revisions is limiting your scope of change control options. So is your use of the Microsoft Word format. I'd reconsider both unless you can: ensure you have a single document owner, and track textual changes independently of your change-control approval process. However, if you can't ...


3

I'd like to address the "demotivating" part of your problem. The most effective tool I have found for addressing these kinds of problems is to break up the time that developers spend doing non-development activity. Funny thing about programmers: most of them only want to program. They don't want to do doc. They certainly don't want to do QA. And most of ...


3

This is still a very complex question, and I think it is possible that an answer will nail a part of it and miss the whole. I'm still thinking about the problem, but in the interim, I found the following quote today The design specification must be governed differently than the requirements. If the requirements were appropriately governed, and if the ...


3

Document the minimum required for a proper, unambiguous implementation. It requires a lot of efforts from both analysts and implementors, so will depend a lot on your project environment maturity. If you're working on a more agile environment, a close relationship and conversation between parts might reduce the amount of extended documentation. If you're ...


3

We differentiate between documentation for: Developers: This goes right in the source code and will be stored in Git. Whenever a function is added or updated, some "text in green" (our wording for developer documentation) has to be added. We write not only details & decisions about a function to it, we add additionally the reason why a decision was ...


2

Ideally I think you'd want someone who isn't a direct part of the development team to be gathering requirements. This is partly because requirements should (depending on your precise situation) go beyond the technical needs of the project to the business needs of the client - something that developers/engineers may not be best placed to advise on. I'm fairly ...


2

In the absence of a PM or a BA, the person(s) who has done functional testing on the product is a good choice for drafting the requirements specs. They can easily reverse engineer their functional test specs into requirements specs. If this formal process ( of having documented functional specs and subsequent functional testing)is not in place, the ...


2

It depends on who is available to you, of course, but I think it is a good experience for the developers to do this. As this analysis happens, they will hopefully be contemplating design, and will ultimately come up with a better design. I agree it may need to be done in smaller batches if possible, to avoid burn-out and attention drift. I've been a ...


2

Customer IS responsible for requirements; however, it is the company's responsibility to organize them and translate into a technical language. Agility of development is a must in the current subset; therefore, make sure that customer gets to see and approve every step of the development (working prototypes). It would be much easier to answer if we knew ...


2

I'm still not sure that I understand the question/problem, and @skilwz's comment leads me to believe that this might be an X:Y problem. There is going to be turbulence & friction if your customer is committed to waterfall, and you're committed to agile. The real problem may be differing conceptions of how to manage change and scope. I also suspect that ...


2

Spikes and Prototypes are Okay; Retconning Project Plans Is Not I was planning to go onto the implementation phase and then to reverse engineer my work. From a project management point of view, this is not okay. Planning is hard, but not planning creates technical debt and problems for the project and the organization down the road. Waterfall is about ...


2

In Business Requirements Document: A High-level Review the author defines business requirements as making reasonable estimates of how big a project is and how much it is going to cost. He then explains what would be in the Business Requirements Document (BRD): The most common objectives of the BRD are: - To gain agreement with stakeholders- To ...


2

Agile Manifesto says: Working software over comprehensive documentation but also! That is, while there is value in the items on the right, we value the items on the left more. So the answer is: as much documentation as necessary, but not more. Definitely do not make a habit for it. Try to avoid to have specification for each requirement just ...


2

There is nothing in Scrum that's keeping you from defining your business entities somewhere and then referencing them in the stories. The agile approach only means you should be able to change those definitions if necessary. You will still need to add details to your user stories, "display an article" is way to broad and open for interpretation, even if ...


2

A user story is an invitation to a discussion. It is not intended to be a detailed specification. All the user story needs to communicate is the basics of a requirement and it is worded in such a way that it is understandable by the person who will derive value from it. As an admin, I can add an "Article" with a title, a content, one or more Category. ...


2

I would make a Template Spec for the similarities. Then each product starts by referencing the relevant Template Specs and then noting the diferences. This way, when you change something system-wide, you don't have to update hundreds of specs. E.g.: GUI: This product is a variation of A - see the spec for A at ________ Other Functionality: This product ...


1

Communicate + collaborate with the person writing the tickets There's really nothing more to say than that. Having a process that looks like this, someone writes the tickets perfectly -> developers interpret the tickets perfectly, is as asking for failure. You can't really make either of those happen, you just need to collaborate. If the acceptance ...


1

Imagine you are going to the hospital and meeting with a doctor to help you because you have chest pain. Do you tell the dr straight away "I have a heart problem, i just read webmd, I need a heart transplant, schedule it for tomorrow"? Obviously, I'm sure you could understand why a dr might grin in this circumstance. What you usually do is say "I have a ...


1

I will answer your question from the point of view of Scrum. User stories may be captured weeks or even months before the sprint in which the work is done. But a user story is a simple one or two sentence description of the requirement. There will be few if any requirement details captured and nothing about the implementation. Because these stories are so ...


1

Another good shooting analogy: shoot, move target over bullet hole, bulls eye! In the real world, when you have a client to whom you are selling your product, this approach will undoubtedly cause a ton of increased expenses, time, and increased risk of client dissatisfaction. The issue is, many poorly performed projects in the IT space are done in this ...


1

There really doesn't need to be a separate goal for accuracy and fraud prevention since these should be handled by standard business policies and procedures. This goal and the associated tasks can be combined in the main flow based on documentation of prior approvals, policy compliance, and employee's supporting documentation. (I've specified the ...


1

The RTM Requirement Traceability Matrix shows how requirements of different level connect to each other, e.g. how a top level customer requirement evolve via several abstraction levels to a specific low level requirement, e.g. a green button. The Requirements Specification Document contains the requirements, e.g. The power button shall be green. You'll ...


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