Tweeted twitter.com/StackProjects/status/1101542792038412288
5 deleted 4 characters in body
source | link

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Example 1 - Splitting one unit A proxy service routes a specific client's orders. It receives, validates and passes on the client's request. A standard intake then handles the request. A change to accept four new values has been split into two separate stories--one for discussing failing validation and one for happy path.

While a user may see two different outcomes, a developer it is handling the contingencies of one new set of input.

Example 2 - One concept, multiple components 10 new events will be reported in two different business categories. Events 1-5 are in Story A. 6-10 are in Story B. Architecturally, Component 1 will receive all 10 events and configuration will handle the detail of each variation. Then Component 2 will consume Component 1's results, again with one mechanism change.

This combines both components into a single story, then does so again. From a developer perspective, the two delineation of work is between components, not event categories.

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Example 1 - Splitting one unit A proxy service routes a specific client's orders. It receives, validates and passes on the client's request. A standard intake then handles the request. A change to accept four new values has been split into two separate stories--one for discussing failing validation and one for happy path.

While a user may see two different outcomes, a developer it is handling the contingencies of one new set of input.

Example 2 - One concept, multiple components 10 new events will be reported in two different business categories. Events 1-5 are in Story A. 6-10 are in Story B. Architecturally, Component 1 will receive all 10 events and configuration will handle the detail of each variation. Then Component 2 will consume Component 1's results, again with one mechanism change.

This combines both components into a single story, then does so again. From a developer perspective, the two delineation of work is between components, not event categories.

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Example 1 - Splitting one unit A proxy service routes a specific client's orders. It receives, validates and passes on the client's request. A standard intake then handles the request. A change to accept four new values has been split into two separate stories--one for discussing failing validation and one for happy path.

While a user may see two different outcomes, a developer it is handling the contingencies of one new set of input.

Example 2 - One concept, multiple components 10 new events will be reported in two different business categories. Events 1-5 are in Story A. 6-10 are in Story B. Architecturally, Component 1 will receive all 10 events and configuration will handle the detail of each variation. Then Component 2 will consume Component 1's results, again with one mechanism change.

This combines both components into a single story, then does so again. From a developer perspective, the delineation of work is between components, not event categories.

4 Added examples.
source | link

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Example 1 - Splitting one unit A proxy service routes a specific client's orders. It receives, validates and passes on the client's request. A standard intake then handles the request. A change to accept four new values has been split into two separate stories--one for discussing failing validation and one for happy path.

While a user may see two different outcomes, a developer it is handling the contingencies of one new set of input.

Example 2 - One concept, multiple components 10 new events will be reported in two different business categories. Events 1-5 are in Story A. 6-10 are in Story B. Architecturally, Component 1 will receive all 10 events and configuration will handle the detail of each variation. Then Component 2 will consume Component 1's results, again with one mechanism change.

This combines both components into a single story, then does so again. From a developer perspective, the two delineation of work is between components, not event categories.

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Example 1 - Splitting one unit A proxy service routes a specific client's orders. It receives, validates and passes on the client's request. A standard intake then handles the request. A change to accept four new values has been split into two separate stories--one for discussing failing validation and one for happy path.

While a user may see two different outcomes, a developer it is handling the contingencies of one new set of input.

Example 2 - One concept, multiple components 10 new events will be reported in two different business categories. Events 1-5 are in Story A. 6-10 are in Story B. Architecturally, Component 1 will receive all 10 events and configuration will handle the detail of each variation. Then Component 2 will consume Component 1's results, again with one mechanism change.

This combines both components into a single story, then does so again. From a developer perspective, the two delineation of work is between components, not event categories.

3 Reframed the subject based on the understanding of the underlying question
| link

Where does describing development work fit in In Scrum, how to handle a functionality that could be used by more than one feature?

2 added 16 characters in body; edited title
source | link
1
source | link