Apr 20


I have believed in using Scrum as a software development methodology since I first were introduced to Scrum back in 2005/2006. After a while I took the ScrumMaster certification (CSM) and started using Scrum as the preferred development methodology. During this time Scrum was getting very popular i Norway. It had become a buzz word and projects were either using Scrum or talking about using Scrum.

The majority of projects that I have been involved in after 2006 have been using Scrum or at least been highly influenced by Scrum. During this period of time I have found my preferred way of using this methodology. In this post I will talk about how I like to use the tools provided by Scrum. This is not a guide on how to use Scrum but more me telling what works for me.


Licenced under Creative Commons Attribution 2.5 by Mountain Goat Software

The image above shows the Scrum life cycle:

  • You have a product backlog defining the product to be developed.
  • Then you have a sprint planning meeting, choosing some tasks from the product backlog resulting in a sprint backlog
  • You start working on the tasks in the sprint backlog for a sprint that should last between 2 and 4 weeks.
  • Every day you have a daily Scrum meeting were all team members answer three questions: What did you do yesterday? What are you planning to do today? Do you have any problems?
  • At the end of the sprint you have a sprint review were you demonstrate the result of this sprint
  • After the sprint review you have a sprint retrospective which is only for the team members and ScrumMaster discussing what went well and what to improve in the next sprint.
  • The sprint is over and you need to plan the next sprint (back to point 2). When the product backlog is empty the product should be ready for shipping or at least testing.

Most of the projects I have been involved in have been quite small projects estimated to 500 – 3000 hours with 3-5 team members.  So what works for me in those projects might not be the best way to work on larger projects.

I like best to work with sprints that lasts for 2 or 3 weeks. I have also tried having 3 weeks sprints were the last week is a “lazy” week. By this I mean that the last week were used for testing, bug fixing and completing tasks that couldn’t be done during the first two weeks. This worked very well for that project because after every sprint we shipped the sprint results to their QA-department, so during the last week we were often fixing or changing functionality from the previous sprint. This is way better than to start doing this at the every end of the project and you have to start working with code developed several months earlier. It’s much more effective to be able to do this just a few weeks after the code was produced.

When I took the Certified ScrumMaster course, Kane Mar was the couch and he did a really good job couching and teaching us how to use Scrum. You can read his blog here. He also taught us how to use ScrumWorks from Danube Technologies to administrate the Scrum process. I find that ScrumWorks is a great tool that replaces the old Scrum board with post-it notes.

scrumworks backlog

The screenshot above shows the main view in ScrumWorks with the product backlog at the right and the sprints with the sprint backlog at the left. I often use this tool to predict when the project will be completed. I add the sprints and populates them with items from the product backlog, this way I can see how many sprints we need to release the product. This is just an indicator since the sprints are not “officially” populated and committed before the sprint planning meeting.

I also like to work with projects that have a product backlog that is not final and only containing a roughly specification for the product. This way the product backlog can evolve during the project. Isn’t that what agile software development are all about?

scrumworks burndown

The image above is the sprint detailed view in ScrumWorks. Here you can see all task for this sprint and the status on the tasks, you can see the sprint main goals and also the sprint burndown chart. This is the view I use when I’m working on a sprint and the main view is the view I’m using when I’m planning a sprint or a complete project.

I like to look at Scrum as a great toolbox containing several tools that can be used in a project. I think that you do not need to use all the available tools, but you can pick the right tools for your project. I guess that Kane Mar would call this “Scrum but” meaning using Scrum, but not using it completely by the book.

Follow me on twitter @PerOla

Share & enjoy
You can subscribe to my comments feed to keep track of new comments.

13 Comments to “Scrum – the way I like to do it”

  1. H. Nilsen says:


    Interesting article, thank you. As a Norwegian Scrum user, I keep wondering why teams would replace the Scrum-board. The board gives an instant overview of where you are in the project, for every party – how can a computer system possibly replace that?

    I feel that using Scrum without the board defies the meaning of Scrum. Please give me your comment on this.

    Best regards,
    H. Nilsen
    Bergen, Norway

  2. Hi H. Nilsen
    I can see that you find the Scrum-board very useful as it is a very good visual tool for keeping track of the tasks. The ScrumWorks detailed sprint view is a digitalized version of the Scrum-board. All tasks are listed sorted by the priority. All tasks have a field for point person (the person working on the task), a task status field were you can choose from; not started, in progress, done and impeded. You also have a hours left field were you can re estimate the task while you are working with it. Another nice thing is the burn down chart showing a graph indicating your sprint progress.
    So ScrumWorks doesn’t replace the Scrum-board it just moves the board to your PC. I used Scrum-board with post-it notes in the beginning, but I find it much easier and more efficient using the digital Scrum-board. It’s also easy to add descriptions to the tasks.

    I hope this answered your question.

  3. H. Nilsen says:

    Thank you for your answer.

    Yes, I agree that it’s more beneficial to use a system like this – and we’re using Agilo for the same thing. But we won’t replace the board, we’ll just double it up with both a board and in the system. Since we use trac (which Agilo runs on) for bugs and stuff, it’s effortless to combine the two.

    Do you still do your daily scrum when you have no tablet to use? Do you plan your day before or after the daily scrum (if you do those, that is)?

    Best regards,
    H. Nilsen

  4. I have never tried Agilo or trac before so I can’t respond to that. I find it hard to include bug fixing in the sprints. Would appreciate if anyone have some tips on how to include bug fixing in your sprint/sprint planning.

    We have daily scrum every morning. We have a rule that before end off day every team members updates ScrumWorks (task status, hours left and point person). This way ScrumWorks is updated before the daily scrum meeting, so I guess you can say that we plan ahead. This is needed since one of the questions at the daily scrum are: What are you planning to do today? How do you guys do this?

  5. H. Nilsen says:

    Firstly, we (or rather I) calculate our estimated capacity during the sprint. Say we have a total of 15 days we’re at work per person, and we’re five members, the capacity is 15*5 days. An estimated 75 days or work during the 4 week sprint.

    For each day, we estimate that we have five hour of actual work done. Giving us 5*75 = 375 hours.

    Now – you need to calculate your velocity. The velocity is how many points you’re able to produce per hour. This is not easy without empirically measuring your points/hours during a sprint. So the first time, just pick a number.

    Say you measure your velocity to be 0.5 points per hour, you know that you can fill your sprint with 375 * 0.5 points = 187 points.

    Pretty simple, actually.

    Since our work day is 7,5-8 hours a day, five hours of work means that you still have 2.5-3 hours to do other stuff – like bug fixing and such. If that’s not enough, for whatever reason, you just lower your capacity when planning the sprint.

    Conservative estimates is key to success. Hmm.. Realistic estimates is a better way to look at it, I guess 😉

    The daily scrum is simply every member answering the following questions to the team: What did you do yesterday? What do you plan to do today? Do you have any obstacles that needs to be handled?

    We need the tablet, to move tasks around, add new tasks, remove invalid tasks etc. etc. The social aspect-, and the easy access to the project outlined on the tablet – for our visitors, our product owner, our users and ourselves – is very important.

  6. Thank you for the detailed description of your Scrum process. It’s always interesting and useful to learn how other Scrum teams organize them selves.

    I started using effort points in the beginning, but I soon found that we were converting the points to hours (like you said the velocity could be 0.5 points per hour). Now I’m using hours as velocity. I know this is not by the book… but it works good for me so that’s my preferred way to do it. We often calculate 6 hours of actual work done during a day, although this differ from team member to team member.

    Realistic estimates and commitment in the sprints are for sure on of the keys to success. The nice result of running short sprint is that if you have committed too many hours or the estimates are blown away it’s easy to adjust this for the next sprint. Learning by doing :)

    In my opinion ScrumWorks is good enough to totally replace the tablet, but that’s my opinion. I guess that it has a lot to do with what your are used too and for sure it takes some time to adapt from tablet to digital tools. When that is said I can’t see any problems by running ScrumWorks and tablet side by side. In the end the most important are the processes and not how you visualize them.

  7. LaszloS says:

    Thanks Per Ola Sæther for blogging about Scrum and ScrumWorks.

    In terms of bugs, just treat them as their own PBIs (product backlog items), and prioritize accordingly.

    In terms of PBI estimation, I would point you back to Kane’s blog. I like his approach which utilizes a spiciness meter – see:

    Best of luck with ScrumWorks – we love to hear about success stories, so feel free to drop my team a line anytime.

  8. Thanks for the tips Laszlos.
    Quite interesting reading Kane’s blog about using spiciness and RSP for estimating story points. I have played a lot of planning poker before to achieve this, maybe I will try RSP the next time.

  9. Pål Berg says:

    Look at this blog Per Ola, this is how we do it at mBricks. We used to use ScrumWorks, but we have now moved to a combination of JIRA and GreenHopper. I think the close integration makes it easier for us to handle the bugs in the Sprint and we “save” the lazy week.

  10. Thanx for the link Pål. It’s always interesting to learn how other Agile (Scrum) teams do it.
    JIRA and GreenHopper are interesting but at this moment I feel that ScrumWorks are sufficient for the projects I am involved in.

  11. Lita Lemelin says:

    Our team’s practice is that severity is the grade of technical affect while priority is the degree of commercial enterprise impact. The tester may determine an initial value to priority, but in the end the last decision on priority is owned by the business collaborator. Also, we attempt to determine definitions for severity that leave little room for argument, while the definitions for priority are more flexible and responsive to business motivation.

  12. Mikael says:

    Velocity is quite simple to calculate: Number of total story points / One iteration

    So if you actually did 25 story points in a sprint (it does not matter how many you actually planed to do). Your velocity for that sprint was 25.

    Neat and simple :-)

2 Pingbacks to “Scrum – the way I like to do it”

  1. […] good friend of mine ask how to include bugfixes in the Scrum sprint, Scrum – the way I like to do it. We have also struggled with this at mBricks, the bugfixes always seems to take attention from the […]

  2. […] is a follow up on a post I wrote earlier about how I like to use Scrum and ScrumWorks for my projects. After writing that post I have had some good discussions on how to manage bug […]

Leave a Reply

Subscribe to my comments feed

Subscribe to my feeds Follow me on Twitter