How to build an MVP with Scrum (draft)

Prerequisites

Groomed Backlog of User Stories

Let's use the one from How to quickly plan and estimate an MVP:

Definition of Done

This is just a list of criteria that can be checked off to verify that a User Story is actually "Done".

They should be short, single criteria, and testable.

Examples:
- Doesn't crash
- Test case coverage
- No typos

Before each sprint planning

Get developers to think about first few stories on their own. This enables more accurate estimates during Sprint Planning since they've already thought about implemenetation of the User Story.

Some common questions to ask themselves:

• Backend work required?
• Database modifications?
• Working with a new or unknown library?

Acceptance Criteria

The Product Owner should also spend time specifying the Acceptance Criteria of each Story. They should know what they want built, so specifying this up front (to be confirmed later by developers) saves time.

These are individual requirements that must be met for the Product Owner to accept the Story. Like the Definition of Done, they should be short, single criteria, and testable. But the DoD applies to all Stories, Acceptance Criteria apply to each individual Story.

Examples for "User can create an account":

• Username must be between 2-20 letters
• User can set a nickname for the account
• Should be all on one screen, not paginated

I've written in more detail previously about User Stories, how to break them down, and how to describe the work required in Story Pointing and Breaking Down Work".

Sprint Planning

This happens at the beginning of every Sprint. First, add the top Stories from the Product Backlog to the Sprint. (These top stories are already in priority order thanks to the Backlog Grooming.)

For example, this team is assuming they can complete these three User Stories by the end of this first sprint. This becomes the Sprint Backlog.

Rough Point Value is the estimated point value from when we initially scoped out the MVP. It will be adjusted or changed completely depending on how accurate the updated estimate will be from the development team.

Estimating Difficulty

This was demonstrated extensively in How to quickly plan and estimate an MVP, but I'll reiterate it here.

How to estimate difficulty?

Relative estimation.

Simple example: how big is A?

Just by eyeballing it, you don't know exactly how big it is in cm or pixels, but you can figure out that it is smaller than B and bigger than C.

If you have two User Stories, it doesn't matter "how long they will take". Is one of the stories more difficult than the other? If so, it will be rated more Story Points.

Do it

There are three stories in our Sprint Backlog:

• User can create an account
• User can view list of store items
• User can view item details

1) From our Sprint Backlog, let's look at "User can create an account". Ask the team to consider how difficult it is, then assign it 2 points.
2) Next, "User can view list of store items". Ask the team: is it easier or harder to build than the first story? The team says it's easier, so assign it 1 point.
3) Finally, "User can view item details". Team says it's harder than "view list of store details", and a bit harder than "create an account". So assign it 3 points.

The Sprint Backlog now looks like this:

Acceptance Criteria

The Product Owner should have already written Acceptance Criteria for each of these Stories. It's now time for developers to verify and clarify each item.

Examples for "User can create an account":

Username must be between 2-20 letters
Devs: Are non-Roman characters (like 이것) allowed?

User can set a nickname for the account
Devs: is this mandatory or optional?

Assign the work

Now that all the User Stories have been estimated and clarified, the dev team can decide who works on what.

Doing the work

While the Sprint is happening, it's important for the dev team to focus on creating value (in the form of completed Stories). The whole point of doing Sprints is to create and release features iteratively so they can be demoed and used as quickly as possible.

Block off contiguous time blocks: Developers need time to actually do the work. Context switching is a huge productivity and motivation killer.

Support devs in any way possible: Provide developers with the tools, resources, and information that they need. If the build environment is too slow, make it faster. If their computers are too slow, get faster ones. If they have questions or required clarification, answer them as quickly as possible.

Focus on fast coding, but slow testing: Quality should be built into any code that's written. To do this, developers should code quickly but test slowly. Invest once in unit and end-to-end tests and get ongoing returns whenever they catch bugs.

Produce something of value: If the Sprint is nearing completion but all the Stories likely won't get released, focus on finishing some rather than half-finishing all of them.

Sprint review

Meeting held at the end of the Sprint in order to inspect what has been produced during that Sprint.

For each User Story that is Done, demo it and answer these questions:

• Does the Story meet the Definition of Done?
• Are all the Acceptance Criteria met?

If those questions are answered positively, the Story can be accepted by the Product Owner.

If those questions are answered negatively, the Story goes back into the Product Backlog (and likely added to the next Sprint.

Recalculate velocity and project forecast

Let's say that two Stories were accepted and one was rejected. Sum the point value of the accepted Stories to get the velocity = 5.

Keep this in mind for the next sprint. Six points of effort were planned but five were completed. But teams should become more effective as time goes on, especially after just a single sprint.

I'd suggest planning for 6 points for the upcoming sprint (but save this discussion for Sprint Planning).

Retrospective

This is an internal meeting for dev team members and any stakeholders who are directly involved with building the product.

In it's most simple form, just two questions need to be discussed: * What went well during the past Sprint? * What could be improved for the next Sprint?

There are numerous ways and methods of going about this which I will link to at a later time.