Switching to Scrum – Part Two
Following on from our Switching to Scrum blog post part one…
5. Terminology: am I a burndown sprint chicken?
The terminology for Scrum IS confusing, no question. Staff might be concerned about getting it wrong or might muddle on through without really grasping it. Have a session or two with *everyone* to cover all the terms involved in the process. Make sure people get it - it’s important they understand the terms because this speeds up communication (which is at the heart of Scrum)
Dangerous Dan Course’s Glossary
The main ones
Agile – A way of thinking and self-organising that responds to Product needs.
Product - The thing you’re building mate!
Vision - The Product Owner sets out the “why?” we’re building this
Velocity – How many User Stories your Scrum Team can handle in a Sprint
Sprint – A two/four week session of work to deliver the next iteration of work on the product
Sprint planning – Taking all the Product Owner’s User Stories and breaking them into tasks
Stand Up/Scrum – A super-quick, daily stand-up project meeting to look at: What was done? What is next? What’s blocking you?
Sprint Review – How did it all go? Did we reach all targets? Can we improve our process? Show your working.
Product Owner - This project is their baby, they ALWAYS choose what’s next. This is normally the client, traditional project lead on internal projects. Determines the project Vision and priorities.
Scrum Master - NOT A PROJECT MANAGER, they purely facilitate the team moving forward and liase with the Product Owner
Scrum Team - All the members in the team making the product
User Story – Get the Product owner to talk in stories about how their product is used, “I want to be able to share my location with my friends”, “I want to be able to switch between my inventory items easily”
Tasks – A breakdown of the User Story by the team. It identifies the niggly bits in User Stories
Done – Work is only ever complete if it’s DONE. Not, “it nearly works boss”, but DONE. No more work needed here
Pig – A Team member who has their skin in the project, listen to them
Hen – Someone who hasn’t got their skin in the project, feel free to ignore their suggestons
Norgen Burgerlator – We made this one up
Backlog – All the User Stories still to do
Sprint Backlog – All the Tasks to do to complete the Sprint
Grooming – Not weird, I promise, just managing your Backlog before the next Sprint Planining Session
Burndown – A summary graph showing work completed and what’s left
Information radiator - All your tickets on the wall – it “radiates” information, see?
6. How should we manage our Tasks and User Stories?
The master backlog of user stories can be a cumbersome beast, especially once you start breaking things down into tasks. We asked ourselves: is it worth writing all your paper tickets up into a digital version? We answered ourselves: we’re not sure! Seems like a lot of work.
We decided to consult Scrum oracle Alex Pitkin “I’m a firm believer in having both paper and digital. Short description on paper, long detail and discussion on the ticket. 1-1 ratio.”
As long as you keep the digital backlog up to date as you go (don’t leave 50+ tickets till the end of the sprint to be written up) then maintaining both makes sense – less chance of anything falling through the cracks!
7. How many hours is a Story point worth?
Now this is something we really struggled with. User Stories are meant to be measured in story points, not in time. Story points are meant to equate to the difficulty of the task to complete, not to the length of time. Teams are supposed to have a good benchmark of how many story points they can complete in a sprint, but how can you know this when you are first starting out?
After much deliberation, we decided what would work for us is planning poker to work out rough story points for each User Story, then breaking each User Story into tasks with time estimates in hours.
8. Done is done is done?
Our first fully Scrum project was tuberank.joinvan.com. We had sprints planned, created a ROI immediately for our client, handled tickets well and most things went great. However, we moved on to new tasks before things were properly declared ‘Done’ with the Product Owner’s involvement. This required a clean-up sprint that sometimes clogged up the studio.
You need to decide what counts as done from the outset of any project e.g. QA’d, minified, fully commented etc? This may differ per project, so make sure EVERYONE is clear.
9. If you buy in, you gotta go all in
Switching to Scrum is not a quick magic bullet, and it’ll take time to adjust to the conceptual and methodological shift. You need to make sure everyone feels the power to self-organise. You need to keep pushing for Scrums, you need to keep pushing for the Product Owner to see the Sprint deliveries. You need to make sure there isn’t project-manager-by-a-different-name trying to organise everything for everyone. And most importantly, you MUST NOT DITCH THE PROCESS WHEN A PROJECT GETS TOUGH! Stick with it, and Scrum should help alleviate Crunch from your projects, making everyone happy, healthy and wealthy.