2 added 2 characters in body
source | link

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

This is a misconception. Neither Scrum nor Kanban require that requirements be specified in user stories. Both are silent on the issue.

The Scrum Guide refers to "Product Backlog Item". These items have only a few attributes - description, order, estimate, value. There's nothing about the format or style required by Scrum, although you do often find the User Story format used. Kanban has even fewer requirements on items than this.

Instead of trying to convert your requirements specification into User Stories, make sure that your requirements meet the characteristics of a good requirement - cohesive, complete, consistent, atomic, traceable, current, unambiguous, have an importance specified, and are verifiable. Then, identify any technical dependencies between requirements and ensure they are prioritized appropriately.

If you're embracing Agile, you'll recognize that your requirements specification is not "finished" - these requirements may change. Instead, focus on the principles of agile software development.focus on the principles of agile software development. Iterate quickly - implement slices of the functionality specified in the requirements specification and get it in front of people who can evaluate the software and provide feedback to incorporate into future iterations. Have your development team work closely with subject matter experts, product managers, and stakeholder representatives to understand the users and their needs. Focus on the higher priority requirements first - you may not actually need to implement everything to be acceptable by the users and can maximize work that isn't done. Reflect and improve on how the team works.

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

This is a misconception. Neither Scrum nor Kanban require that requirements be specified in user stories. Both are silent on the issue.

The Scrum Guide refers to "Product Backlog Item". These items have only a few attributes - description, order, estimate, value. There's nothing about the format or style required by Scrum, although you do often find the User Story format used. Kanban has even fewer requirements on items than this.

Instead of trying to convert your requirements specification into User Stories, make sure that your requirements meet the characteristics of a good requirement - cohesive, complete, consistent, atomic, traceable, current, unambiguous, have an importance specified, and are verifiable. Then, identify any technical dependencies between requirements and ensure they are prioritized appropriately.

If you're embracing Agile, you'll recognize that your requirements specification is not "finished" - these requirements may change. Instead, focus on the principles of agile software development. Iterate quickly - implement slices of the functionality specified in the requirements specification and get it in front of people who can evaluate the software and provide feedback to incorporate into future iterations. Have your development team work closely with subject matter experts, product managers, and stakeholder representatives to understand the users and their needs. Focus on the higher priority requirements first - you may not actually need to implement everything to be acceptable by the users and can maximize work that isn't done. Reflect and improve on how the team works.

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

This is a misconception. Neither Scrum nor Kanban require that requirements be specified in user stories. Both are silent on the issue.

The Scrum Guide refers to "Product Backlog Item". These items have only a few attributes - description, order, estimate, value. There's nothing about the format or style required by Scrum, although you do often find the User Story format used. Kanban has even fewer requirements on items than this.

Instead of trying to convert your requirements specification into User Stories, make sure that your requirements meet the characteristics of a good requirement - cohesive, complete, consistent, atomic, traceable, current, unambiguous, have an importance specified, and are verifiable. Then, identify any technical dependencies between requirements and ensure they are prioritized appropriately.

If you're embracing Agile, you'll recognize that your requirements specification is not "finished" - these requirements may change. Instead, focus on the principles of agile software development. Iterate quickly - implement slices of the functionality specified in the requirements specification and get it in front of people who can evaluate the software and provide feedback to incorporate into future iterations. Have your development team work closely with subject matter experts, product managers, and stakeholder representatives to understand the users and their needs. Focus on the higher priority requirements first - you may not actually need to implement everything to be acceptable by the users and can maximize work that isn't done. Reflect and improve on how the team works.

1
source | link

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories.

This is a misconception. Neither Scrum nor Kanban require that requirements be specified in user stories. Both are silent on the issue.

The Scrum Guide refers to "Product Backlog Item". These items have only a few attributes - description, order, estimate, value. There's nothing about the format or style required by Scrum, although you do often find the User Story format used. Kanban has even fewer requirements on items than this.

Instead of trying to convert your requirements specification into User Stories, make sure that your requirements meet the characteristics of a good requirement - cohesive, complete, consistent, atomic, traceable, current, unambiguous, have an importance specified, and are verifiable. Then, identify any technical dependencies between requirements and ensure they are prioritized appropriately.

If you're embracing Agile, you'll recognize that your requirements specification is not "finished" - these requirements may change. Instead, focus on the principles of agile software development. Iterate quickly - implement slices of the functionality specified in the requirements specification and get it in front of people who can evaluate the software and provide feedback to incorporate into future iterations. Have your development team work closely with subject matter experts, product managers, and stakeholder representatives to understand the users and their needs. Focus on the higher priority requirements first - you may not actually need to implement everything to be acceptable by the users and can maximize work that isn't done. Reflect and improve on how the team works.