Agile eLearning development (4): Planning and execution


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:

Comments

  1. The current development time for an e-learning module is 400 hours and 40 man days. You have been asked to reduce this to 350 hours and 30 man days. Provide a structured approach on how you will go about this exercise:
    1. Explain the requirement gathering phase
    2. Identify the detailed steps you will take to impact this change
    3. Discuss the risk mitigations
    4. Evaluate the effectiveness of the change
    5. Plan for organization-wide roll-out

Trackbacks

  1. […] Agile eLearning development (4): Planning and execution […]

  2. […] Planning and execution This post describes the agile way of planning and estimation through story points and the concept of done. I know that story points have some disadvantages as does the ‘traditional’ way of planning. I like it and if you would try it out it will definitely give you some new insights in your planning and development process. […]

  3. […] 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).  […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,064 other followers

%d bloggers like this: