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.

http://ukhairtransplantclinics.co.uk/?cir=can-you-buy-propecia-in-mexico Product - The thing you’re building mate!

strategie di trading con opzioni binarie Vision - The Product Owner sets out the “why?” we’re building this

anyoption deutschland erfahrungsbericht Velocity – How many User Stories your Scrum Team can handle in a Sprint

http://irinakirilenko.com/?deribaska=60-sekunden-trade-demokonto&710=0f 60 sekunden trade demokonto 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?

opzioni binarie sicure garantite Sprint Review – How did it all go? Did we reach all targets? Can we improve our process? Show your working.

http://sigmacreativeonline.com/website-design-development Roles

http://www.aaronhaxton.com/?eiwo=forex-affiliate-pay-per-lead&644=e9 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.

http://achievementcenters.com/?RANDnids4=testimonianze-guadagni-opzioni-digitali&cac=bb 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

Meta

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

Weird ones

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.

See How do Story Points relate to hours thanks to Alex Pitkin, but also Stop using Story Points!

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.

Tags: , ,

Leave a Reply