Week 2

Question 1

What is a story?

Answer 1

Users describe what they want the system to do when they perform a specific action. Each action is called a story. Each action just does one thing.

Question 2

What are epics?

Answer 2

Stories that are too large. Epics can be broken down into smaller stories.

Question 3

What is a story card?

Answer 3

It’s a piece of card, about 1/4 of an A4 sheet of paper.
Store info in an easy, accessible way.
Prevents too much documentation.
Delays decisions - details are deferred until they are needed

Question 4

What info does the story card contain on the front and back of the card?

Answer 4

Front: story name, short description of the user story, conversations between the developer about the story.

Back: series of tests. If all tests work then the story has been completed. This is a test-driven approach.

Question 5

Why are tests so important?

Answer 5

The capture exceptions and provide an acceptance test for the story.

Question 6

When is a story considered to be finished?

Answer 6

When it has passed all acceptance tests.

Question 7

How do you manage stories properly?

Answer 7

• Stories should be closed once they’re finished
• Focus on near goals
• Keep the UI out of the code for as long as possible

Question 8

What is a paper prototype?

Answer 8

Designing the user interface with a series of mockups

Question 9

What are features of good stories?

Answer 9

• independent of other stories to avoid confusion
• negotiable
• valuable to users or customers, but not developers
• estimable
• small but not too small
• testable

Question 10

What is a spike?

Answer 10

A spike is a story that is specified by the developers, rather than the users, to learn more about the issues.

Question 11

Can very small stories such as bug fixes be combined into a single story?

Answer 11

Yes, it’s easier to estimate the time for a group of bug fixes rather than one

Question 12

How do you find a story?

Answer 12

Identify user roles. What would each user want to do? Each action is a separate story.

Question 13

What is the main purpose of a user role?

Answer 13

To generate stories. Many different users can have the same role, and so are treated the same.

Question 14

Why are non-human system roles useful?

Answer 14

If another computer system will interact with our system, then it will generate stories.

Question 15

What are internal stories?

Answer 15

Developer written stories. Not provided by a user. Developers generate spikes.

Question 16

How are user roles recorded?

Answer 16

User roles are recorded on an index card or on e.g. Jira.

The name of the role
Frequency of use
Domain expertise
Computer expertise
Software expertise
Goals

Question 17

How do you find user roles?

Answer 17

User roles are brainstormed by the team. Each member of the team thinks of user roles independently and writes cards for them.

Organise the initial set by overlapping cards where roles overlap.

Consolidate roles, removing duplicates.

Refine roles by adding details

Question 18

What are personas?

Answer 18

It’s sometimes useful to invent a person or several people, to represent a user role. This often makes it easier to guess some details when implementing a user

Question 19

What are extreme personas used for?

Answer 19

Boundary cases. These can reveal rare bugs.

Question 20

What are user proxies?

Answer 20

Sometimes real users are not available but some other person from the organisation is. They can provide inaccurate data.

Question 21

When should acceptance tests be written?

Answer 21

Before coding

Question 22

What is a backlog?

Answer 22

A collection of all stories, including epics, is called the project backlog.

Question 23

What is an iteration backlog?

Answer 23

Stories that have been assigned to an iteration and are yet to be worked on.

Question 24

What are story points?

Answer 24

The amount of effort required to complete a user story.

Question 25

How are story points usually defined?

Answer 25

1 story point to one ideal day.

Question 26

What is the typical length of a story?

Answer 26

1-4 days

Question 27

How are user stories estimated?

Answer 27

Each developer secretly writes down an independent estimate of the number of story points required.

Once the estimates are revealed, developers with the longest and shortest estimates explain their reasoning.

Each developer then makes another estimate and this process continues until the estimates converge.

Question 28

What is MoSCoW?

Answer 28

MoSCoW is used for prioritising stories.

Must have
Should have
Could have
Would like to have

The priority will often depend on the cost.

Question 29

What are non-functional requirements?

Answer 29

Requirements that cannot be expressed as a user story. These cards are labelled as constraints and they have length 0.