Requirements and Planning

Requirements and Planning >> Agile Software Development

*Please Do Not Click On The Options.

* If You Click Mistakenly Then Please Refresh The Page To Get The Right Answers.

1 point

User stories are tokens for conversations.

To be valid, a story MUST follow the following syntax template: “As a ____ I want to _______________ so that ____________________ .”

Stories can be written at different levels and can be refined and split into smaller stories as you move from vague idea to implemented software.

All stories have to be the same size.

User stories are used to plan, design, describe, build, and validate your product.

1 point

They help you write tests cases for the story.

They can potentially help you split stories, if required.

They help the product owner (who is writing the story) think through the user needs.

They help build a common understanding between team members.

They make sure the story is easy to develop.

“As a product owner, I want a list of highly-rated restaurants on the brochure.”

1 point

It doesn’t specify the value of the story (the “why” is missing).

The user who benefits from this story is missing (the “who” is missing).

The story is not small.

The story is not negotiable.

“I want the software to be easy to use.”

1 point

It is not testable.

No valid user is identified.

The story is not valuable.

The story is very big.

1 point

At any given time, the level of detail may be different for different parts of the software.

The agile way supports progressive refinement—defining the right level of detail at the right time.

Agile encourages conversations as a key method for building a shared understanding.

In agile, we don’t waste time on understanding user needs. Instead, we build something, show it to the user, and learn.

1 point

Sometimes, you keep it free-form for people to write stories and later group them by theme.

The leaders from the organization lay out exactly what needs to be built.

Everybody silently writes user stories around a theme

User role analysis and defining personas

To generate stories, one of the options is to start from the top down or bottom up.

1 point

It is a user-centric approach where we map out the system from a user’s perspective.

Only the product owner and users attend the story mapping exercise.

The horizontal axis (moving from left to right) in a story map represents time.

The vertical axis (moving from top to bottom) in a story map represents rough priority.

One story map can only have one user. It is not recommended to have multiple users on same story map.

The velocity range to be used for the release planning is 15-22.
The team works in 2 week iteration.

Table 2: Prioritized Product Backlog

Story Title	Estimate (in ideal days)
Story 1	5
Story 2	5
Story 3	8
Story 4	3
Story 5	5
Story 6	5
Story 7	3
Story 8	5
Story 9	8
Story 10	8
Story 11	3
Story 12	3
Story 13	3
Story 14	5
Story 15	8
Story 16	3
Story 17	5
Story 18	5
Story 19	8
Story 20	8

1 point

Most likely: Story 1 to Story 8; Might Be Done: Story 9 to Story 13; Not likely: Rest of the stories

Most likely: Story 1 to Story 9; Might be Done: Story 10; Not likely: Rest of the stories

Most likely: Story 1 to Story 11; Might be Done: Story 12 and 13; Not likely: Rest of the stories

1 point

Plan just enough, just in time.

Use Adaptive Planning.

Plan as little as you can. Planning is considered a non-productive activity.

Planning is mostly done by project manager.

1 point

It is a velocity of the individual team members, not the team

It is calculated at the team level and represents how much work a team can get done in an iteration.

It is calculated at the team level and represents the estimated duration of current iteration.

It represents actual work done in the first iteration of project.

Requirements and Planning >> Agile Software Development

Requirements and Planning

Related Questions & Answers:

Leave a Comment Cancel reply