“Three Amigos” is what Matt Wynne calls the meeting to discuss the Gherkin scenarios before development starts. The Three Amigos involves the business, development and testing voices. However who turns up, where they meet, what they produce in the meeting, the homework to complete after the meeting, and who does that homework can all vary depending on the particular team.
When Kanban folk talk to Scrum people the conversation can often get heated with recriminations and finger pointing. Personally I’ve got a pragmatic, or eclectic, style of Lean-Agile. None of the published methods are the silver bullet. But they all have something useful to offer.
“Stand up please”. Old habits die hard and because I started Agile with Extreme Programming I “Stand up”, I don’t “Scrum”. Otherwise the two types of meeting are pretty similar. “What have you done since we last met? What will you do before we meet again? Any impediments?”
Great meeting. Wrong questions.
As Mike Cohn explained back in 2006, and Matt Wynne reminded me last year, the daily meeting is a Planning session. It is part of Mike’s planning onion because the aim of the “Stand up” is to develop the plan for the day.
Today I bumped into an article Bryan Zarnett wrote for the Scrum Alliance. I read the article mainly because the title caught my eye in Google – Running the Scrum of Scrums: Agile Program Management.
This leapt out at me because of the claim that the Scrum of Scrums is the same as Agile Programme Management. It isn’t.
Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.
There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.
Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.
I’m a Scrumbut and I’m proud of it.
Simon Baker (@energizr) recently tweeted “If ur a scrummaster protecting the team is a bad move. Help the team fend for itself. Shielding ppl from the big bad world creates ignorance” (04 Sep 2012). Simon might be right about creating ignorance, but the Scrum Master as a shield might also be good for delivering the project.
Jim Highsmith proposed two simple strategies for successful software development: Build Less, Start Sooner.
Jim’s observation is genius, but I would add “Innovate Constantly”.
This is what having a large number of tasks unfinished at end of Sprint looks like:
It is best to avoid over commitment so the answer to “What do I do When Tasks in the Sprint Plan are not Finished?” is to lower your expectations next time you go into planning. Using Scrum language you should ensure the team only commit to what is achievable, and that is obviously less than they thought was possible the last time around.
You’ve also got to tidy the up the mess left by the previous Sprint. Have a look at the unfinished tasks and decide if they are necessary for your high priority user stories. If so, then schedule them into the next Sprint. If not, then forget about them.
Finally, you have to decide what credit you can give yourself, i.e. what velocity you earned in the previous Sprint. Personally I start hard line about this. You can only claim a user story if it is completed, so you can only add the story points for that user story if all the tasks have been completed. No partial credit.
Having said that:
- If you find that the unfinished tasks are actually unnecessary then you can claim credit for the whole user story.
- It is sometimes possible to split a user story into meaningful sub-parts. If one of the sub-parts has been completed then you can claim the story points of the sub-part for velocity
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.
So your boss comes to you mid-sprint and demands a new oscillating-email-ingest-engine. Right now. Nothing else is higher priority.
Scrum says “Say no”. I think the discussion is more nuanced.