I finally found time to create version 2.0 of "Scrum and XP from the Trenches" :o)
No revolutionary changes. Just wanted to clarify some chapters, add some missing info, and add some new knowledge gained since the first version.
- Added a chapter on planning poker.
- Added a chapter on how the team decides which stories to include in a sprint & what the product owner can do to affect this.
- Clarified how we use velocity metrics in sprint and release planning.
- Added a chapter on what to do if the product owner doesn’t want to attend the sprint planning meeting.
- Added a chapter describing why quality is non-negotiable.
- Added a better picture of the design corner.
- Added more details on how we do retrospectives, including a whiteboard photo.
- Added more on offshoring and distributed teams.
- Lots of minor corrections and clarifications.
Enjoy! And thanks for all the valuable feedback.
On page 15 you write: “Sprint planning meeting: 13:00 – 17:00 (10 minute break each hour)”
My question is what is the reason behind 10 minute break each hour?
Is it when the decision are being discussed/lobbied in smaller groups by the coffee machine?
Well, the 10 minute break is really intended to be just that – a break! Otherwise the efficiency of the meeting degrades after a couple of hours as people get tired and unfocused.
Of course, there’s nothing stopping people from continuing the meeting at the coffee machine during the break. But we’ve found that it still helps to leave the room and stretch those legs a few minutes each hour.
Hi Henrik,
I just finished reading your Scrum from the Trenches publication and I must say I am extremely impressed. I showed some guys here at our office excerpts of some of your ideas and successes and they were all excited by the way you approached and redifined some of the problems you saw.
We have also decided to try and use this document to create something similiar with a focus on web development instead of software development. Although I must say my knowledge is not nearly as complete as yours it is an adventure that your publication has motivated me to take with my team.
If we ever finishing something as extensive as this I will be sure to credit you and pass along a copy.
Thanks.
Thanks for your feedback. I’m glad to hear that the paper has prompted you to try Scrum in other areas!
I’ve tried applying Scrum (or parts of Scrum) in many non-software environments including party planning, course administration, and band rehearsal management. Works quite well actually! Although in non-tech circles I tend to avoid telling people that we are doing Scrum, since that just confuses everyone.
‘Huh? A process? Um, listen we’re just trying to plan a party here, let’s not carried away’ :o)
Many people don’t realize just how simple and lightweight Scrum can be if you want…
/Henrik
Hi Henrik. You write (page 39).
Have you seen the new "super sticky notes". They might be the answer to your problems. I use them as often I can get my fingers on them in our office supplies here at Capgemini 🙂
Highly recommended 🙂
Cool, thanks for the tip!
Hi Henrik,
We are having product development projects and projects are development+maintenence projects. Is it fair to calculate focus factor for the entire sprint or we should calculate focus factor for development against the reserved development capacity?
Generally when we calculate for the entire sprint, the reason for varying fcous factor is more/less support work….
What is your opinion on this kind of project scenario