Better Sprint Planning with QA Alignment

From CitconWiki
Revision as of 10:59, 3 October 2015 by Glook (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

(scribe started late due to discussion)

Coming in at story size.

Each story should be a single testable unit.

story size regression can be googled for information.

The language that you use doesn't matter that much as long as you agree on it.

The release team, the epic, and the story. The story is As a user, I want to be able to click open so that 'goal name'.

Elephant carpacio. In the early days of agile, developers who were jerks wanted really thin stories. That is a skill and it takes work. They were taking the difficult job and giving it to the product owner.

Asking the developers to write the story can be a challenge. Asking them to break it down further is a bigger challenge.

What's wrong with a five day story? I want faster feedback.Making things simpler for everybody?

Focus on the team.

A five day block can freak someone out. I don't want to know at the end of five days that it needs another five days.

When a bug enters, you don't have the five days any more, now it is going to take longer.

One thing we haven't done is asked the developers "what's your biggest frustration?"

What if it is performance work? It's not a UI, so talking about what needs to be done from a functionality perspective.

The realm of "Illitys" Non-functional requirements...

Maybe a timebox? Investigate and define things to be done.

Point based planning had a choice of 1 2 or 3 points. More than 3 points meant that you didn't know.

The concept of spike is discussed.

Doing something that is shorter can allow for finding out how long something will really take.

A story can not be broken down beyond a unit test. There is no obligation to release a simple open.

How do you coach the philosophy change of simple stories?

Breaking down stories is done by developers. There is a business statement. Developers all estimate together. But what if there is an expert developer that could do it sooner? You pair. But I can't.

Pairing can be presented as training on the job.

(commitment is a graphic novel about project management)

Allocation based on least liquidity first.

A discussion follows on superstars on a team and the value they do or do not bring.

Is this a team sport or not? We can all come up with examples where the superstar didn't get the championship.

The question is "Are you looking to win?"

You have a choice about releases, getting as much done, or a certain amount committed to. Which do you value? You don't get maximum amount with a commitment. Do you value getting more done or getting what you committed to get done.

Let's make the assumption that there is another team that could make this commitment and deliver. What does that team have that we don't and how do we become that? What is under our control?

Wherever you are in the skilled linear curve you can be much better. It has to be a team result.