5 Practices Better to Change in Your Scrum Implementation

My deviation: Instead of story estimation I introduced “story matching”: we take each story from this Sprint and try to match it with a story (or several stories) from the last sprint.

Pros: (1) Easier to match stories than to estimate them. Also, seems more accurate (2) Changes in velocity are built into the technique.

Cons: When starting to work on a story, harder to know its “weight”

BTW, what do you think about the Nokia test? I often have doubts about such tests. I sometimes feel that the only test for agility is a nice linear burn chart.

We use another form instead of hours. We are using AP (Arbeitspakete). We break down the whole work into small tasks todo and than burn down those APs. It works fine after some iterations when you know about how small the pakets should be. This idea is from johanna rothmans great book “manage it”.

The funny thing is: The Scrum coaches teach their own deviations each.

They told us to estimate functionally not by effort. This way the estimation meeting remains a strategic meeting. The Product Owner can do the the release plans without effort estimations because of the law of big numbers.
Thus the Team is more likely to improve because estimations remain stable even if technical constraints change. “If this functionally is a 1 and we don’t want to have a future velocity of 1 we build a framework, to improve our velocity.
But what we did: Some of the same coaching company promoted a combination of effort and functionality, so called complexity estimation. This leads to Sprint-Planning2-style estimation meetings where developers try to understand what to do exactly. Additionally the estimates change as soon as the technical constraints change. Or two story estimations change when you change their order in the backlog, because they depend on each other, which kills the whole idea of the independent-story idea, which in turn is their to make the release planning easy. I.e.: Estimations should be stable/reliable and thus only accurate enough and thus functional seems to be the best way to estimate.

We were taught to only have a story point burn down chart (based on the estimations of the stories and only updated when stories are finished). No need to have numbers on tasks, instead rather distracting.

Last we were taught to not sprint-plan with estimations (as their are for release planning only). Nevertheless the team is doing it, to feel safer. Probably one of the other coaches of the coaching company told them to do so :-(

@Stefan: Ah you! :-)

I’d think if you only estimate functionality you need to know what to do (frontend, backend). Even function points are technology dependent (e.g. how many backend systems data goes to etc.)

If you estimate pure functionality (what’s that?) then you’d end up with “velocities” of 10,25,87,3,17,…. This I recon wouldn’t help product owners with release management.

I try to steer developers to a type of function point estimates, while at the same time asking them “is this planning 2 or needed for estimation?” This most of the time helps with not going into Planning2 discussions at estimation meetings.

The goal should be to not estimate anymore but have flow. The only use of estimation meetings is to teach product owners to right-size user stories.) If they can do that, drop estimations :-)

“We were taught to only have a story point burn down chart (based on the estimations of the stories and only updated when stories are finished). No need to have numbers on tasks, instead rather distracting.”

Often when only having story points, and the first stories are to big, the burn down chart will be a flat line which goes vertical towards the end. Doesn’t help very much with seeing progress in effort and business value.

Hi,

dont´t you find it hard to know that you will be ready in time without some kind of estimation of the tasks? I can see a risk that instead of (together with the product owner) take away a story to save time, you will speed up in the end and in that way reduce the quality.

I also think it is strange to take away the review meetings, knowing that you will present your work can prevent you from making a shortcut in a solution.

You also write that it will go faster to test, that sounds strange to me. Do you mean that test is not a part of the user story?

@Stefan (the Codemonkeyism one):
Are you doing Scrum or Kanban?
If you have no review meeting but frequent customer reviews, why should you need iterations?

How long are you doing this now? And how old is the product (before or after release 1.0)?

@Sebastian: Ah, one from the famous Scrum shops in Berlin :-)

“Are you doing Scrum or Kanban?”

Scrum.

“If you have no review meeting but frequent customer reviews, why should you need iterations?”

I do hope we have not iterations in 6 months.

“How long are you doing this now?”

4 months.

@Magnus:

“I also think it is strange to take away the review meetings, knowing that you will present your work can prevent you from making a shortcut in a solution.”

The review is done after each finished story for each story together with stakeholders and product owners. Not in one meeting for all stories.

“You also write that it will go faster to test, that sounds strange to me. Do you mean that test is not a part of the user story?”

Most companies have a QA department with a QA phase. This usually starts after review. When the review is sooner, the story can be tested earlier (Testing by developers, acceptance testing and unit testing is done during development, regression testing in the QA phase).

In the long run one should drop the QA phase, have some exploratory testing ad do most of regression testing with automatic tools. Most companies are not there yet. Dropping review meetings (in the Scrum sense) drops the “waiting for QA” buffer.

I am a newbie when it comes to Scrum, but I am very interested in all that, and I am currently leading the move to Agile in my company for about 2 weeks now.
Nevertheless, I have my opinions about your post too.

1. No Review Meetings
I disagree on this point. A sprint is supposed to have a goal, defined by a statement. Something like “All Search feature are finished” for instance.
The review, in my opinion, is supposed to verify that this goal (and not necessarily each user stories) is reached, and approved by the product owner or the customer.

3. No hour burn down chart
I’ve never used hours on the burndown, Always used the storypoints. Actually, on a small 6 months project last summer, we used only storypoints, and never refered to hours anywhere, that worked fine as well. :)

4. We do not use Velocity for Sprint Planning
I am currently reading the book Agile Estimation and Planning by Mike Cohn, and according to him, this is not something modifired I think. he describes both way of creating and estimating the sprint backlog. velocity driven, or commitment driven. Both have advantages and drawbacks, but using one or the other depends on the situation, or maybe just of the personal preferences of the team. Though, his preference goes to Commitment :), and mine too.

@Stephane:

“A sprint is supposed to have a goal, defined by a statement. Something like “All Search feature are finished” for instance.”

The sprint goal has been the weakest point in most Scrum implementations I’ve seen. Perhaps it’s hard to get right.

“Both have advantages and drawbacks, but using one or the other depends on the situation, or maybe just of the personal preferences of the team”

Interesting to know, read the book, probably forgot :-)

(TooManyBooksReadMemoryEvictionExceptioN)

Stephan,

It is ok to me skip review for SOME (less valuable) stories and present them while Sprint is running. But, at least as how I think about Review, it is a public meeting, and so, anybody can come in to offer feedback. This is why I think that is not ok completely skip the review meeting. Moreover, I can’t understand your point about “stories going faster into testing”. Testing is a requirement for done, right?

About the “ready” state for stories be “more work for the ProductOwner” and “possible be additional waste”, it only happens if you try to put to much stories in your ready state. Put stories enough for the next 1 or 2 sprints only.

Kind Regards

@Marcos: As said before, most companies have a distinct QA phase before release. This is different than acceptance & unit testing.

If you do not need a QA phase, good for you. Keep it that way.

For companies with a QA phase: It can be reduced by dropping review meetings and doing starting the QA phase as soon as a feature is done.

For example:
You develop a feature/story in the first 2 days of a sprint. You’re sprint is 2 weeks. The the feature will wait for QA for 8 days. Doesn’t make sense :-)

If your story goes live directly after it’s finished (continous deployments), hurray!

Stephan,

I was not talking about drop QA people, but about do QA as an activity that TEAM must do to change a story from “in progress” to “done”. For sure you should have QA activities, but I think they fit better inside the team. In other words, the story is done when all the work – including QA – is done.

Sorry, by QA people I mean QA phase.

kind regards

“In other words, the story is done when all the work – including QA – is done.”

If that already works at your company, keep it. Most companies have distinct QA phase and need to transition towards lean.