Last March I was given an interesting new project to work on:
- The aim of the project is to deliver an interactive educational resource discovery tool that enables staff or students to answer a pedagogic or learning question they are trying to satisfy.
- The tool will act as a bridge between the technology enhanced learning (TEL) services and the people who want to use them.
The seed of this project had sprung up from several colleagues working in learning technology support, it was inspired by the Service Options Graphic which was created to give an overview of the services offered in the Learning Services Team.
The graphic proved very useful as tool both for promotion and supporting staff but quickly people started to say ‘if only we could have an interactive version of this….’
Initially it was hard for me to see how to translate this excellent if vague idea into an online tool. Fortunately Steph Hay joined both Information Services and this project in September 2013. With our small team complete and a tight deadline we decided to use an Agile Project methodology. Learning from the expertise of others in Information Services who have already used this approach: https://www.wiki.ed.ac.uk/display/insite/Agile+Projects (Page behind EASE).
Agile projects are iterative and deliver more frequent releases of software. There is an emphasis on interaction and customer collaboration. They should be simple and reflective and take working software as the primary measure of success. [https://www.wiki.ed.ac.uk/pages/viewpage.action?pageId=174606387 (Page behind Ease)].
Steph was then lucky enough to see a presentation given by colleagues in Applications Development ‘Darwin, Finches, and Poker Chips: An Agile Journey’ which they would later present at the Educause 2013 Conference.
She came back enthused and said our first steps were clear, we needed to find out what users want and the tools for doing this were ‘user stories’ – and poker chips.
Gathering User Requirements
At the end of last year we started by running several requirements gathering workshops using the ‘User Stories’ technique. This allowed us to capture user requirements in everyday language without thinking about technology. User Stories are written in the form:
As a/an……
I want to…..
So that…….
The short workshops took 1 hour and started with a brief introduction to the project and the technique. We then moved on to the main activity of discussing the project and getting the participants to complete the User Story Cards. Evaluation of these events was positive and included some nice comments: “interesting, fun, worthwhile!”
We also undertook a survey of teaching staff which received 148 responses and from this were able to add some additional User Stories and to see that a number of the user stories gathered from the workshops had broader support.
After reviewing the User Stories we had a group of 41 requirements. We then gave each a weighting which reflected the amount of effort we estimated would be required to implement this. These were numbered in the Fibonacci number series: 1, 2, 3, 5, 8, 13, 21, 34 (this was as high was we needed). This sequence was used as the sharp rise in the numbers reflects the uncertainty that is introduced to any estimation as you become less certain of how to implement a requirement. It also allows an easier way to agree on the estimation of effort as the difference between effort 8 and 10 is difficult to quantify while a difference in effort between 8 and 13 is easier. Each requirement and its weighting was then printed out onto A4 card for the prioritisation events.
In January, to prioritise the requirements we ran ‘poker chip prioritisation workshops with users’. I had optimistically advertised the events as ‘both informative and fun’. (I may have even mentioned Vegas at one point, but was sensible enough not to put this in writing!). After a brief introduction we gave each participant 20 poker chips and asked them to read the requirements (laid out across several tables) and to play the correct number of chips (either individually or in together) to vote for an item. This led to some interesting discussion as proposals were made and deals where cut. Steph and I where both impressed that this technique fulfilled our original expectations: it meant we engaged fully with the requirements and had them reviewed by several groups of users.
Where next?
So now; we have a set of working requirements and will shortly start the first iteration of the build phase. The vague initial idea is starting to move towards something more tangible and as we are using an agile process there should be working software to test soon.
Also, we are currently surveying staff across the university to decide on a name for this tool, and so hope to have something far more meaningful to call it by the time we write the next blog post on the subject.
Links
Further details of this project are on the Projects Website.
You can subscribe to the project mailing list to be kept informed of project activity and to receive invitations to participate.
