Kasper Spiro
CEO of Easygenerator

When using an agile approach there is a different way of making estimations, you don’t calculate hours but use story-points. Story points are a number indicating the difficulty of a user story (and thus indicating the amount of time/cost it will take to build it).

First estimation

When we start on a new version of easygenerator we will from a business perspective assign priorities to the user stories. Very large developments (epic) stories are divided into smaller stories that fit in one sprint. The development team will give rough estimations on the stories with the highest priorities (the ‘must haves’ and ‘need to haves’). Based on these estimations the priorities are reviewed by the product owner and me. Sometimes when you see that it will take a lot of time to complete a user story you will decide that it is not that important after all, and vise versa. This way the user stories are organized by priority in the backlog.

meten

Grooming and estimates

User stories that are initially produced by the product owner sometimes need some refinement, this is done in so-called grooming sessions. The development team will discuss the story with the product owner, asking questions to get the story and the requirements clear. The user story are updated after this session with the outcome of the discussion. After grooming the team will make a final estimation in story points. For example 3 points for a simple story, 8 points for an average story and 13 points for a difficult one. When you have a groomed backlog with final estimations you know how many story points the work is you have in the backlog.

Each sprint the team commits to a number of stories and afterwards you will know which stories they have actually finished. The total number of story points done in a sprint  is called the burning rate and determines the development velocity. After a while you will know how many points your team can burn in a sprint and you can calculate the time needed to develop all stories. We work with certain release dates and often the total number of story points (and needed time) is higher then what you have available. In that case you have three options.

  • again go through your backlog and look at what is really a must have and skip some stories
  • increase the capacity of the team
  • move your deadline towards a later date.

Usually we choose the first option. And I like this. You have a triple filter before deciding to build something. First the original prioritization, then after the rough estimation and finally  the second prioritization after grooming. This is a good thing, it ensures that you will only build what is really needed and nothing more.

When the team starts developing you will see every week how many story points they are burning (we work with one week sprints). If this is lower then expected, you will know very soon and you can take measures (try to increase the velocity, or again review the priorities of the must haves). You can steer at very short notice and this is really great. An ideal way to time box development.

Done

User stories will only be presented at demo when they are done. Done means that you could decide to put them in the production version of the product straight after the demo. So build, tested, documented, translated and meeting all the requirements. Requirements are the requirements that where in the user story, but also general requirements for performance and UI.

eLearning

This method of planning and execution can be used for eLearning development without any changes and I promise you it will be a huge difference.

This post is part of a series on agile eLearning development:

The Learning 2019 conference

4 years ago by 2 min read No comments

I have been to a ton of learning conferences but this will be my first time at #learning2019. I’m looking forward to it and I’m planning to report on all interesting sessions via this blog.

· · · · ·