Bắp nếp: Scrum - Architecture & Release and Sprints

I. The Influence of Architecture Vision on Team Velocity and Software Quality

How to Identify Architecture Vision

There are two things the team can do.

One is to look at the product vision and goal to identify the main business data that would support that product vision, or pertain to that business domain, as some experts put it.

Or see which core user-visible stories share the same common business data grouping

For example, all book reservation stories should have some common data related to the book and its characteristics.

Create the Data Architecture

II. From the Architecture Vision to Release and Sprints

Example : The central library system

Horizontal Slicing

Horizontally slicing means that the team can envision developing the software product by creating the foundation for the key data elements and entities across all the rings, starting from the core in the middle to the outermost ring.

Vertically Slicing

Vertically slicing means the team could develop the software product by creating the foundation for all the data elements and entities, ring by ring.

Tracing Sprint Goals back to Release Goals

Sprint backlog organized by Sprints and by Release

How We do Sprint Planning

Sprint planning meeting agenda

Ex: Sprint planning meeting: 13:00 – 17:00 (10 minute break each hour)

Defining the sprint length

Well, short sprints are good. They allow the company to be “agile”, i.e. change direction often. Short sprints = short feedback cycle = more frequent deliveries = more frequent customer feedback = less time spent running in the wrong direction = learn and improve faster, etc.

Defining the sprint goal

The sprint goal should answer the fundamental question “Why are we doing this sprint? Why don’t we all just go on vacation instead?”.

Deciding which stories to include in the sprint

Estimating using velocity calculations

1. Decide estimated velocity

2. Calculate how many stories you can add without exceeding estimated velocity

Velocity is measurement of "amount of work done", where each item is weighted in terms of its initial estimation.

Let's say we are planning a 3 weeks sprint ( 15 work day ) with a 4 person team. Lisa will be on a vacation 2 days. Dave will only 50% available and will be on vacation 1 day. Putting all this together...gives us 50 available man-days for this sprint.

Because our unit of estimation is story points which, in our case, corresponds roughly to "ideal-man days". Focus factor is an estimate of how focused the team is. A low focus factor may mean that the team expects to have many disturbances or expects their own time estimates to be optimistic.

The best way to determine a reasonable focus factor is to look at the last sprint (or even better, average the last few sprints).
Actual velocity is the sum of the initial estimates of all stories that were completed last sprint.

What if the team is completely new so you don’t have any statistics? Look at the focus factor of other teams under similar circumstances.
What if you have no other teams to look at? Guess a focus factor. The good news is that your guess will only apply to the first sprint. After that you will have statistics and can continuously measure and improve your focus factor and estimated velocity.
The “default” focus factor I use for new teams is usually 70%, since that is where most of our other teams have ended up overtime.

Definition of "Done"

It is important that the product owner and the team agree on a clear definition of “done”. Is a story complete when all code is checked in?
Or is it complete only when it has been deployed to a test environment and verified by an integration test team?
Whenever possible we use the done definition “ready to deploy to production” but sometimes we have to make do with the done definition “deployed on test server and ready for acceptance test”.

Tech Stories

Ex: Install continuous build server

Why it needs to be done: because it saves immense amounts of time for the developers and reduces the risk of big-bang integration problems at the end of an iteration.

Write a system design overview

Why it needs to be done: Because developers keep forgetting the overall design, and thereby write inconsistent code. Need a “the big picture” document to keep everyone on the same page design wise.

Try to avoid tech stories. Look hard for a way to transform a tech story into a normal story with measurable business value.

If we can’t transform a tech story into a normal story, see if the work could be done as a task within another story. For example “refactor the DAO layer” could be a task within thestory “edit user”, since that involves the DAO layer.
If both of the above fail, define it as a tech story, and keep a separate list of such stories.

How we communicate sprints