Skip to main content
grammar
Source Link
nvogel
  • 6.3k
  • 1
  • 10
  • 28

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing. As the teamsteam works along a narrowing cone of uncertainty the instances of analysis-only stories should tend to be fewer.

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing. As the teams works along a narrowing cone of uncertainty the instances of analysis-only stories should tend to be fewer.

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing. As the team works along a narrowing cone of uncertainty the instances of analysis-only stories should tend to be fewer.

added 187 characters in body
Source Link
nvogel
  • 6.3k
  • 1
  • 10
  • 28

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing. As the teams works along a narrowing cone of uncertainty the instances of analysis-only stories should tend to be fewer.

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing.

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing. As the teams works along a narrowing cone of uncertainty the instances of analysis-only stories should tend to be fewer.

Source Link
nvogel
  • 6.3k
  • 1
  • 10
  • 28

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to be sufficiently ready so that the current sprint goal is achievable.

Alternatively, teams will sometimes create analysis-only stories - stories which will define further work that gets completed in future sprints. This is reasonable for example if the PO needs certain details to be worked out in order to create or prioritise new backlog items. It's a very common thing to do at the beginning of a new product or workstream. This still doesn't have to mean every detail is defined before sprint planning because the BA should still be able to contribute during development and testing.