Enhanced Scrum Guide

Hey Arnaud,

I had a quick read of your enhanced guide. I like it, it contains some good practices and might help beginners to get a good start.

I saw one thing which I wouldn't recommend: Tracking how many story points are done.
I recommend using story points for estimating, they just represent the complexity - thats it. I prefer to use burnups and count the number of task cards instead of dealing with story points.

Cheers
Joerg

Thanks much fr your comment Joerg, I am pleased you consider it a good help for beginners. As for the story points, I use them all along, but it s the purpose that is useful, not the mean, so if a team prefers another way of tracking the job done, it s fine. The most important for me is to track what they spend work on everyday, it s really useful at retro to find impediments.

How do you measure the time spent per story DONE compared to READY estimates?
Also, how do you track what non sprint items team members spend (lose) time on?

Thanks again!

Posted By arnaud viguie on 07 Apr 2016 09:16 AM
The most important for me is to track what they spend work on everyday, it s really useful at retro to find impediments.

Why is it important to you to know what each team member is working on, or that each team member is busy? How does that promote self-management within a team?

“Customers don't pay for busy people. Customers pay for awesome products and services. Manage work, not workers!” – Klaus Leopold

Well Timothy, you answer to the post but you have not checked the guide, else you would not have misunderstood that much my comment.
The point is not to track to micro manage, the point is to have a tool to log what the team spends time on, so that at the retro that info helps THEM, the TEAM, finding what slowed them.

Arnaud,

You stated fairly clearly in this forum that it is important to you to track what the team works on everyday, hence my question to you. I am glad that your response was that it is important for the team to be able to assess their productivity and possibly address any gaps in their retrospective discussions.

I would ask though that you refrain in the future from directing inquiries to your Enhanced Scrum Guide, effectively replying "don't listen to what I said here, read elsewhere what I meant".

For your information, I did read your "guide" when you first posted. I chose not to reply or provide feedback, because I do not wish to go down that rabbit hole.

I do not think your "enhanced" version is beneficial. The errors and inconsistencies between your modifications and the real Scrum Guide may impede understanding and adoption of Scrum, in my opinion.

Timothy,

What rabbit hole is there? I have no ads i dont sale anything, this is not a commercial offer or anything, i just tried to make something useful and asked fellow scrumers here to help me correct what should be.

If you read the guide, then i dont understand how you could misunderstand my statement about the tracking, since i wrote quite clearly in it that its only purpose is for the team to self check and improve.

More importantly, I would be glad if you could point out the inconsistencies and errors i ve made in it, so that i could improve it.

Thanks by advance

More importantly, I would be glad if you could point out the inconsistencies and errors i ve made in it, so that i could improve it.

That is the rabbit hole.

Then, if you do not want to help improve it, like Joerg usefully did, i dont understand your point. but that s fine, lets stop pollute the thread. I hope i ll get more helpful feedback.

> I do not think your "enhanced" version is beneficial. The errors and inconsistencies between your modifications and the real Scrum Guide may impede understanding and adoption of Scrum, in my opinion.

+1, regardless of whatever noble intentions you might have had in doing this. If you had noble intentions, I applaud them.

I have no interest in improving something I fundamentally do not agree with.

The Scrum Guide is intentionally vague on several points, so trying to fill in that vagueness in what appears to be a concrete specific way, defeats the concept of a framework being flexible and extensible.

Charles, have you checked it?
There is no specific way, half of it is about XP practices like TDD, BDD, pair programming, some examples of tools to help defining a backlog notably story mapping, good practices like advised by Jeff Sutherland on scruming prime lab about swarming priority stories...
You make it sound like i wrote a prescriptive methodology, really makes me wonder if you checked it. as i said in it, i propose a process among many. when you begin scrum and read the official guide you have no clue about what is a story map, or that multi tasking is so wrong. i gathered in one place the advices and recommandation found on scruminc, mountaingoat and others.
i dont understand your reaction.

The "enhanced guide" reminds me the story of the book "Scrum and XP from the Trenches".
The author states clearly that he described the "current" practices of his team at this time. But then, a lot of people took it words by words.
I worked with a Dev Team that was stuck by the focus factor, which is a technics from this book. The author explained latter that this was the very first technic to forget !
Then he wrote "Scrum & XP from the trenches version 2" and "Scrum beyond the trenches" to correct this kind of issue.
As Charles states, Scrum is left intentionaly as a framework.
Turning it into a "comprehensive method" seems very dangerous to me.

Arnaud, yes, I read the first few pages before I decided I did not like the concept -- and some time after I made the comment above. I think you should stop assuming that people haven't read it. Why would they bother commenting on it if they haven't read any of it?

A big part of your challenge, IMO, is calling it the "Enhanced Scrum Guide", implying that it is somehow a better a version of the Scrum Guide. Instead, it should be called "Arnaud's View of Scrum" or "Arnaud's Comments on Scrum practices" or something that sounds less official.

Arnaud, perhaps this can give you a bit of perspective.

From your self-proclaimed "Enhanced Scrum Guide":

"(Have you read the pmbok -589 pages- or prince2 -420 pages- manuals? The original Scrum Guide explains the whole framework in just 16 pages, that’s already agile!)

That is very true! A lightweight framework, devoid of any implied "best practices", and applicable in a variety of ways.

Now, your "Enhanced Scrum Guide" is at least 50+ pages long, and contains a significant amount of links to additional definitions, concepts, and practices referenced in your blog. To me, that's not agile.

I'm reminded of the tag line from the game Othello: "A minute to learn, a lifetime to master".

While well-intentioned, and perhaps reflective of your Scrum journey and some of the "better" practices that you've experienced and learned about along the way, it simply is not presented in a way that would benefit your intended audience (beginners, new scrummers). No one starting out on their Scrum journey will be able to shorten their learning curve by trudging through your brain dump as presented of Scrum knowledge and experiences.

Perhaps some of the content in your blog can benefit specific question about Scrum practices (focused topics!), but as a whole, it is unfortunately a rambling mess.

If you believe there are concepts in the Scrum Guide that need enhancing, it would be best to raise each of them individually here first. That way we can help you through better focus.

The document you have created is a work in progress, and a large one. I recommend limiting your WIP.

Posted By arnaud viguie on 07 Apr 2016 09:16 AM
The most important for me is to track what they spend work on everyday, it s really useful at retro to find impediments.

Even without tracking how many story points are used I would expect team members to state in the daily where they are working on. It is transparent if the task card is not moved or if another related one is added. If there are impediments this should also be mentioned. So my point is even without the question "how many story points are used?" you will find the topics to discuss later in the retro.

Posted By arnaud viguie on 07 Apr 2016 09:16 AM
How do you measure the time spent per story DONE compared to READY estimates?
Also, how do you track what non sprint items team members spend (lose) time on?

I recommend not to measure/compare the time spent to any estimates. (You might refine esimates in a backlog if you have additional information. I don't recommend to refine estimates when a team has started with a user story.)

The only thing that counts is the team commitment: "Which stories will we deliver until the sprint end?" In the retro check with the team if the commitment was good/ how it could be improved next time.


Summarized: My opinion is tracking is not agile and from my experience managers are interested in it. There is no benefit for the team. The sprint commitment from the team is all you (and the mangers) need.

Cheers
Joerg

Thanks Joerg.

Olivier, you re right, i did it in a similar way than "Scrum and XP from the trenches", because such lecture really helped me. But in the guide i paid attention to add that tools and practices are a mean, not a finality, and that hiding behind a tool is more zombie scrum than smart. Also, (and i will recheck that right after), i did not write that one tool has to be used, i only said in a particular situation, you may use this tool.
I also never wrote "best practices", and you went a bit fast over as i specifically wrote that there is no best practices in agile, as it is not prescriptive, but rather you have to chose which tool is right depending on a situation.

But most of the added content are undisputed (i think) principles that are really helpful to learn about, such as:
- dont let your team be disturbed,
- dont multitask,
- stop starting, start finishing : swarm the stories as a team
- have really READY stories,
- have a proper definition of DONE,

Those things are examples of what scruminc advised in its video classes, so guys if you find that prescriptive i dont understand. as it s written inside, the purpose is to provide some tools and advises to answer questions that any beginner has after just reading the scrum guide. Is it ok to be part time? can we adapt sprint length depending on the size of our stories? is it ok if the scrum master is also a dev team member? that s the kind of questions i answer, and those answers, again, were not originaly mines bu those of people like jeff surtheland or mike cohn. and yes i put lots of link to those sources for the readers who want to expand on a topic.

for Timothy: "There is no best practices in agile, as your situation and context will define which ones you will use, and how. That makes agile in general and the Scrum framework in particular more difficult to master than traditional, bigger prescriptive methodologies, as you can’t just learn and apply from the book: agile requires you to think, try, check and adapt. And that cycle concerns both the products you develop and the way you develop them.

However, there is a set of useful tools and practices that helps A LOT to get the best of agile in general, and Scrum in particular."