The technology industry is full of jargon. Constantly developing, changing and growing, new words and methods are evolving each day.
Here are a few phrases you might find useful when working with a software development company using agile methodology to build or develop your LMS.
Agile
‘Agile’ is a term you have no doubt come across. It has become a common and reliable way of working for developers across the globe.
Agile is the method of working incrementally in ‘sprints’ (see #2) rather than using the traditional waterfall method, where projects are worked on for longer building up to one release date.
What are the benefits of working this way? The name says it all.
The agile way of working means the team can work in a more flexible way, constantly re-assessing and testing the work.
The agile way of working is as much about you – the client – as it is about the development team. You are involved at every step and can see exactly what progress is being made throughout the process.
Graphic by BuildEmpire Ltd
Sprints
The agile way of working allows teams to break down a project into user stories (like a to-do list), prioritise the stories (see #5) and then work on them in (typically) two-to four-week cycles, called ‘sprints’.
Each sprint will have a collection of stories in and at the end of the sprint that section of the work will be deployed (see #4). At the end of each sprint, you will see progress. You can make alterations as needed, constantly reassessing and inputting into the development process.
For example, one sprint might have a collection of tasks such as:
- Add a comment box for course material
- Introduce engagement points for learners
- Add a skills tracker for educators
- Build a progress tracker for learners… etc.
Depending on how long these tasks will take depends on how many tasks can be fit into each sprint.
PRs
In the tech world, PR stands for ‘Pull Request’. This is essentially when a developer asks, “Can you pull my work into your work?”.
To add more context to this, developers very rarely work on live sites. They work on copies and then when everything has been tested on the copy, the new work is pulled into the main repository.
PRs mean that the work is constantly being reviewed, which keeps it at a high level, helps avoid bugs and gives you peace of mind.
For example, one person may be working on Task A: add a comment box for course material (using the examples above); whereas another developer might be working on Task B: introduce engagement points for learners.
When ready, they both need their work pulled into the main code and tested.
Deploy
The term ‘deploy’ shares a similar meaning to the original military use of the word. But rather than deploying troops, we are deploying code.
The word deploy is used when code is transferred to a server. This is not usually straight to the live site, but usually to a staging site first and then once it has been reviewed here it will be then deployed to the live site.
One deployment will usually move several tasks, each of which has had their own PR and have been checked individually, to the server. Deployment is an exciting time as a client, as you can see things happening often and see your project taking shape.
Going back to our examples, at this stage you will now be able to see the points tracker and the other changes on the staging site. You can now test it out and feedback to the team.
Story
In dev terms, a ‘story’ is a task. The word ‘story’ is used because each issue raised should be phrased in a story-like way to give the developer full instructions with no room for misinterpretation.
They are written from a user’s point of view, explaining how they would use the feature. This way it is clear how the developer needs to build the feature based on how the user would use it.
For example: “As a user, I would like to be able to view my completed courses so I can track my learning journey.”
If you are particularly active in the development of your project, you might even write some stories yourself.
Storypointing
To understand storypointing you must first understand that ‘pointing’ has nothing to do with directing someone’s attention towards something, nor does it have anything to do with masonry. In this context, ‘pointing’ relates to adding a numerical value, so allocating points.
So, as you can imagine, ‘storypointing’ is when the team allocate a value (based on effort needed) to each ‘story’. Then, based on the ‘points’ the team can plan it into the sprint.
This is very useful, as a client, to be able to see an accurate representation of how much work is being processed every week.
For example, ‘As a user I would like to see the comments box labelled as ‘my notes’ so I can use this as a revision tool’ might only be 2 storypoints, whereas ‘As an educator I would like to see what skills my class have practised in each module so I can personalise their learning’ might be 13 points.
Software you might use for raising tasks and storypointing are YouTrack and JIRA.
Here is an example of how your story and storypoints might look in YouTrack:
Graphic by BuildEmpire Ltd
Retros
Short for ‘retrospective’, retros are an opportunity for you, the development team and any other shareholders to gather and reflect on how a sprint has gone.
Did everything go to plan? Was the storypointing accurate? How can we be more productive or accurate in our planning next time?
This is valuable taking stock time before the next sprint commences. A chance for you to reflect with the team and then feed what you have learnt into future planning.
For example, you might see that the ‘labelling’ task should have been allocated 3 points because it required testing on different platforms.
You might also see that the number of storypoints completed over time is not steady, so you might want to look at why certain days of the sprint were more productive than others.
Burn downs
Burn downs sound exciting. And they are, if you are into graphs. A burn down is a chart which shows the expected rate of progress (using storypoints) during a sprint compared to the actual rate of progress achieved.
You will be able to see exactly how much work was output and at what rate throughout the sprint, compared to predictions made prior to the sprint starting.
Graphic by BuildEmpire Ltd
Different software companies may have different names for processes, but if you get a company who knows what they are doing you will find the basics will be consistent.
The best advice I can offer is that if a team is using a term you are unsure about, simply ask.
Teams may forget they are using internal jargon and need reminding. Our language changes at such a rapid rate, and there is never any shame in asking for clarification.
Most developers I know love an excuse to talk about their processes – it is what they are passionate about after all.
This is a guest post by Aimee Ward, Marketing Manager at BuildEmpire.
