The Power is in the Points

How hard is it to estimate how long something will take? The answer is very hard!  But why is this?  Well, there are a few key factors. Mainly, the problem with time is that in a short space of it anything can happen.  It is unpredictable. Estimating in time is risky.  Secondly, people aren’t actually very good at estimating how long things will take.  How many times have we heard “how long will that take?”, only to hear the reply “how long is a piece of string?”.  Sometimes tasks are so massive, we just cannot begin to get our heads around it.   People are, however, much better at measuring how complex a task is.

Let me explain…

If someone pointed at a messed up Rubik’s cube and asked me “Is that complex to solve?”.  Personally, I am really not very good at those things, so I’d be like “Err, YAH!”.  I don’t need to know much to know it is complex.   Complex doesn’t mean ‘hard’.  It’s not exactly ‘hard’, I mean it’s just moving some squares around, but its complex because it takes a lot of thought, and there are so many combinations to process as I move the pieces.

Now, if the same person then asked me “How long will it take you to solve that Rubik’s cube?” I would have absolutely no idea.

This is why in Scrum we measure complexity of work in story points as opposed to in time.  Once the team understands the concepts around points and planning poker, they get pretty good at measuring complexity.  It turns out it is a much more accurate measure of forecasting estimates than time alone ever will be, and this makes story points powerful.

Advertisements

Education, education, education!

If you are a ScrumMaster or Agile Coach working with a new Scrum team(s), it goes without saying that it is really important to spend the majority of your time at the start of your deployment investing in training the team.  Obviously by ‘The Team’, I’m not just talking about Dev/Test, I’m talking about Product Owners too.  If you don’t do this, you will end up with a confused and frustrated team because they will not know the Scrum process OR what is expected of them as part of a collaborative self-organising team.  You need to be tenacious in delivering a clear, consistent message to your team about what Scrum is about, both as a development framework, and as a culture, and be constantly checking on their development as a learning team.

If you know your stuff, it is much easier to start training your team than you think because there are some fantastic online resources to help you deliver a really great session.  I am a big fan of the CollabNet Agile e-learning training series (http://www.collab.net/services/training/agile_e-learning ), and at the moment, it is a major element of my training session’s agenda.  Speaking of which, here is the agenda I use for Scrum Introductory training:

  • Presentation (you should put a few slides together for this):
    • What is Agile, and why did it come about?
    • Definition of ‘Agile’
    • What is The Waterfall Model and why is Agile different?
    • The Agile Manifesto
    • Other Agile frameworks that are around, e.g. not just Scrum, but Kanban, XP, DSDM etc.

I then use the entire CollabNet interactive training series to train the team.  I use the Quizzes and questions provided in the series to ask the room what they think the answer is.  I also take the time to explain why an answer they have chosen is NOT right, and why another answer IS.  This is a really important part of their learning, and means they will have a better chance at understanding the logic to Agile rather than just learning parrot-fashion, but not really getting ‘why’. The session takes around 2.5-3 hours, depending on questions.

If I have Product Owners to train, I run the above session in the morning, and then hold an afternoon session with the following agenda:

  • What is a PO’s role and responsibilities?
  • What makes a great PO?
  • How to be a PO at <the company you are in>
  • Requirements: What is the difference between a granular User Story and sn Epic User Story?
  • Introduction to a real life Product Backlog
  • How to maintain a Product Backlog, including prioritisation of User Stories
  • How to write excellent User Stories and Acceptance Criteria with an exercise. (The group will be split into pairs/small teams and will write  User Stories and Acceptance Criteria for a real project, followed by a discussion)
  • How to Prepare the Product Backlog properly for a Backlog Refinement Meeting or Sprint Planning
  • Q&A

If you do this, you will get everyone in the Scrum teams off to a great start.  However, it is also really important to keep their knowledge up.  I hold fairly regular ‘open desk’ sessions, where I block out some time and invite people to come and talk to me and ask me anything about Agile.

Finally, teach (theory), demonstrate (real-life application), repeat.  I cannot stress enough the importance of reiterating a constant and consistent message. At the Scrum Board, in the stand up, at the retrospective, one on one, in training session, all the time.  Being consistent with your approach allows familiarity and the team encourage the team to trust that you are serious about what you say and you won’t also move the goal posts for whatever reason.

Story Time! Yey!

Do we like story time? Of course we do! Story time is great! We also like this name far more than ‘Backlog Grooming’ which just sounds wrong…

So what is so great about Story Time? Well, are you sitting comfortably? Then I will begin…

Once upon a time there was a meeting called the Sprint Planning Meeting and that was held at the beginning of every sprint in a faraway place (it seems far away to a developer if it is not at their desk…) in a land called ‘Meeting Room’ and it took a lonnng lonnng time. The Sprint Planning Meeting had a very looonnnng time box (8 hours for a month sprint, proportionately less for shorter sprints) and it made the Scrum teams very very tired and not want to go anymore because it was soooo lonnngggg…

Ok, so you get the picture, Sprint Planning can be boring and take ages…So, as a ScrumMaster, what can you do about it and what is Story Time anyway?!

Story Time is also known as the Backlog Refinement Meeting, or Story Elaboration Meeting and it should be scheduled to occur a day or so before Sprint Planning. The point of the meeting is to get the dev/test the team together with the Product Owner (PO) to go through the top priority backlog items that are candidates for the next sprint. The MAIN PURPOSE of this meeting for me is to make sure the whole team understand the requirements of the product Backlog Item (PBI) in question, and provide a gut feeling as to whether it is possible to complete it in the sprint. I know, right?! Gut feelings as opposed to knowing for sure? This sounds like fiction! Especially to all you command-and-control traditional Project Managers out there (naw, bless….sucks to be you).

It is important to stress that the team do not commit to anything in the Story Time meeting; they are just assessing what could be possible to get done in the next sprint. There are two reasons why I find this meeting is great: Firstly, because by the end of the meeting, the PO and the team are on the same page when it comes to the requirements for the top priority backlog items, and secondly, it shaves time off your lengthy Sprint Planning Meeting because the team are already familiar with the story and the requirements. For a two-week sprint, I keep Story Time to a two hour time box. This is not too little, not too much, but is just right to keep the team focused and engaged and most importantly, clear on the requirements for the top priority backlog items.

For a great video on Story Time, see Andrea Druckman’s 60 Second Scrum YouTube video: http://www.youtube.com/watch?v=KRZ201j1ZUk