Recently I was fortunate to be able to run a learning session with my team. I decided to run my session based on the Elephant Carpaccio workshop to see if we could all think more about how user stories can be effectively split up.

The original workshop

If you haven’t come across the Elephant Carpaccio workshop before it’s based on Alistair Cockburn’s awesome article of the same name. It’s a great explanation of the benefits for slicing user stories into the smallest possible size and deliver them incrementally. I’m a big proponent of small user stories, however reading Cockburn’s article again it reminded me that once the elephant has been sliced as finely as possible, it is important that once the slices are all delivered they still need to resemeble the elephant.

It’s important to note that while stories should be sliced as small as possible, the story should be sliced vertically. This means that a story should go through all layers of the infrastructure and still deliver value. As such if there are a lot of layers of infrastructure required to deliver a story, then it needs to reduce in size horizontally. For example when building a new form, the new page will be needed, any logic for processing the form data and storing the data will all be needed. So the first story might be very thin horizontally and only be for a single field on the form. A lot of value is still gained from such a story as a lot of knowledge will be gained. The following story may be the rest of the fields on the form as vertically a lot of the work has already been done.

In the original workshop you spend some time deciding on how best to slice the user stories to deliver a checkout that can calculate total price, discounts and tax based on the location. If you ever get the chance to take part in the work shop I definitely recommend having a go.

My version of the workshop

For my session I only had around 30 minutes, so unfortunately I couldn’t do the full workshop. I wanted to do something that was open to non-developers as well as developers and show the importance of thinner user stories.

I put together a list of different features for a hypothetical website and asked the group how they thought they could best be broken down. I split the group into pairs and they had 3 minutes to decide what work they thought they could release in a day. At the end of each 3 minutes, I marked off which features, or which parts of features they felt they could have released.

Before the start of the session I assigned each feature a value increase to over all sales for the hypothetical website, and this sales increase was split over the parts of the feature. The first part of each feature was given greater value. I wanted to show that stories don’t necessarily need to be grouped and completed by feature, but you should target the most valuable stories first.

After several rounds, I added up the overall impact each pair would have made on sales.

My workshop Rules

Aim of the game

To increase sales for the website as possible

Scenario

I’m a widget seller who sells 2 types of widgets. Type A and Type B. I want to improve my website to sell them more effectively. Below are the baseline expected sales figures

• Widget A - 50 a day
• Widget B - 100 a day

The checkout is already in place and took 3 days to complete. Please use this a reference point for the size of implementing new features.

Below are the features that I want my site to have and impact I expect them to have on sales of widgets. The sales impacts are once a feature is fully implemented, benefits can be gained from partially implemented features.

• Product information page - 30%
  • Text
  • Image
  • Reviews
  • Related products
• Product gallery - 10%
  • carousel
  • quick view box
• Banner carousel - 10%
  • Overlay text
  • Image cropper so I can put various images in
• FAQ - 20%
  • Customers can ask questions
  • Customers can answer questions
• Store Finder - 5%

How the sesson went

Overall, I would say that the session turned out to be a success. Everyone seemed to enjoy it and it raised some good discussion and thought over how its best to tackle the most valuable stories first, not just fully complete a feature.

The group were very helpful and gave me some really constructive feedback for the next time I get to run the session. Firstly it was to lower the 3 minute timer for each round, it was too long and it gave people time to chat about other things. Also, I had a spreadsheet to calculate the impact on sales each team was having, however the more astute members of the group were keeping on eye on which features were getting the other teams a lot of value and going for that themselves. As such, next time after each round I would just show them the overall results, not how they were calculated.

One thing I did learn to take in to future workshops is that you can really motivate a group of people by turning a session in to a competition with cookies as the prize.

I’ve finally got around to setting up my Arduino Uno, a few minor teething problems and I’m away!

I love seeing some of the projects other people have done by using an Arduino. I can’t wait to get that good and be creative with it. For example, check out this secret knock detecting door lock

The first step was to get the Arduino IDE. As I’m working on Ubuntu and still a Linux newbie this in itself presented me with some challenges. My first attempt was was by using the Ubuntu package manager. However I realised that the packaged version of the IDE was quite old. At the time of writing this post, the apt-get package was 1.0.5, but the version available for download was 1.6.7. So I decided to manually install the IDE.

As the Arduino tar came with an install script I didn’t have to run configure and make. So after moving the extracted folder to the /opt folder, I was able to give the install script executable permission and run it. I found this set of instructions very useful.

Pretty impressively, the Arduino IDE comes pre-loaded with a quite a few examples. The setup example I was working through pointed me towards the Blink example.

Initially I was getting an error when trying to upload onto the board;

ser_open(): can’t open device “/dev/ttyACM0”: Permission denied ioctl(“TIOCMGET”): Inappropriate ioctl for device

I found another very helpful article here. By following the instructions on the article I was able to add my user to the dialout group and change the filer permissions on /dev/ttyACM0. After this was done the blink example uploaded just fine. While this isn’t the most exciting thing in the world you can do with an Arduino. It was awesome to know that I had successfully uploaded my first program to my board.

Interestingly, once I had uploaded blink, I then wondered “how do I stop it?”. It turns out that there isn’t such a thing as stopping the Arduino. So unless a stop was part of the program (where it wasn’t in blink) it would just keep going until the power supply is stopped.

Now to move on to more interesting lessons!

As I’m trying to improve my Javscript knowledge I’ve started working my way through Nodeschool’s Workshoppers. If you haven’t come across the Workshoppers before, they are brilliant. They are self contained Javascript (among other things) lessons that come in the form of a Node module. If you are anything like me, actually doing, really helps to make the lessons sink in rather than just reading.

For example, run the below commands and you are up and running;

npm install -g scope-chains-closures
scope-chains-closures

Lesson 1 - Scopes

So a pretty straight forward one here, setting a variable within the scope of a function. However, one of the things I liked about this module is that they also give information as well as set the challenge for the lesson.

So it was nice to learn that scoping with a function is actually called lexical scoping. Also, that ES6 has block scoping but you use “let” rather than “var”.

Solution

function foo(){
    var bar = 1;
}

Lesson 2 - Scope Chains

Here we are looking at how scopes can be nested and that a variable from an inner scope will have access to an outer scope but not vice versa.

Solution

function foo(){
    var bar = 1;
    function zip(){
        var quux;
    }
}

Lesson 3 - Global Scope

It was interesting to see how forgetting to declare a variable with “var” would create that variable globally. With my background in C#, this seemed pretty strange to me and will be something to be careful of.

Solution

function foo(){
    var bar = 1;
    function zip(){
        var quux = 1;z
    }
    quux = 2;    
}

Lesson 4 - Closures

Closures are a term that I have heard of before in Javascript but never really known what they are, so it was nice to find what they actually were.

When an inner function references a variable from up the scope chain, its closes over it and is a closure. The closure and the variable are maintained even if the inner function isn’t called immediately, and the function can be passed around.

Solution

function foo(){
    var bar = 1;
    quux = 2;    
    
    function zip(){
        var quux = 1;
        bar = true;
    }
    
    return zip;
}

Lesson 5 - Garbage Collection

Obviously Chrome dev tools is something I use all the time, but this lesson showed me tools in there that I haven’t used before. Recording the memory profile on the timeline tab to see where garbage collection took place was very interesting. Its always useful to have another technique to help analyse site performance.

If you want to get my solutions to ths Node School module, you can get them from my repository here.

If you’ve not heard of sphero then I recommend you go check them out now. They are a remote controlled sphere with a bluetooth connection and they are a lot of fun. There are plenty of apps available to control a sphero and its nice to see that there are even some for Windows phone. Unsurprisingly though the majority of apps are available for ios. They do look cool though, you can draw with the sphero, shoot aliens and play golf just to name a few. However I wanted a go at making my own controller.

Orbotix have made loads of SDKs available. Ruby, Python, Arduino, PhoneGap, OSX, Node, Unity, Android and more. I decided to use sphero.js as I’m still teaching myself Node as well. Installation of sphero.js was pretty straight forward by following the instructions on the github page. As I’m currently using Ubuntu, I did have to do the extra steps to allow the dialout group permissions to the bluetooth port.

The only problem I had, was that I had to use sudo when running node app.js due to the elevated permissions. May be obvious to others but as an Ubuntu newbie, had me stumped for a bit. If you are also on Ubuntu I would also defintely suggest getting the Blueman Blutooth Manager rather than the built in bluetooth app.

After getting up and running, I decided that I was going to focus on controlling the colour of sphero to start with. Making it zip around was fun, but I was too lazy to keep getting up and retrieving sphero from under the couch. If you have more energy than I do and want to get the full list of commands commands available on Javascript API the docs are available here.

I built a simple Express app that connects to the sphero on start up. As with most of my simple Express apps, I went with EJS for the rendering engine over Jade. Not because I have a problem with Jade, I just find the straight markup in EJS a little bit easier to work with usually.

I added a few colour buttons for control, good old bootstrap to the rescue for button styling! When each button is pressed it fires a basic jquery ajax post to a pre-defined route wich in turn changes the colour of the sphero. I went for an ajax call so the page didn’t have to refresh each time the sphero changed colour.

To know that the call had fired and just to make the controller look a little nicer I put a css circle with a gradient on to change the same colour as the sphero. On app start I had the sphero turn white so its clear everything is connected properly. To make the css circle look a little bit more like a sphero I used this nice article for how to apply 3D gradients to circles.

The next thing I aim to do is turn the controller in to a memory game where you have to copy the list of colours that the sphero flashes. If you want to keep track of my controller, you can find the repo here

As a developer it can be very useful to use principles such as SOLID and the Four Rules of Simple Design to help me write better code. But it struck me that it might be helpful to apply the SOLID principles to writing effective user stories.

SOLID Principles

So a quick recap of what the SOLID Principles are firstly. They are a list of principles to help create easily maintainable object-orientated code introduced by Robert Martin. Thanks Uncle Bob!

• Single responsibilty principle
• Open/closed principle
• Liskov substitution princple
• Interface segregation principle
• Dependency inversion principle

Single Responsibilty Principle

A class should only have one responsibility.

It struck me that user stories can become overly complicated and try to cover too many requirements. If a user story is broken down to its smallest possible size I think it helps the story to move across a kanban board more easily.

The developer working on it will have a clearer idea of what is expected of them. Testing time should shorter as it will be clearer if it has succeeded or not. Risk of deployment should also be reduced smaller changes will be going to production.

Just as a single class can have many tests, a single responsibilty user story can have many acceptance criteria.

If a user story adds value once complete, then I can’t really see how a user story could ever be too small. For example if a form is required, I would be tempted to identify which fields are absolutely required then they would be one user story. Each added value such as email validation or user name checking should be a user story in their own right. This is because value can be gained without them and more value will be gained with them.

Open Close Principle

A software entity should be open to extension but closed to modification.

So new features in software should be able to be implemented by adding new code to extend the currect functionality, by using inheritance for example. You shouldn’t need to modify the existing code.

I think user stories can behave in a similar fashion. When slicing a new feature each story should keep adding value on top of the value from previous tickets. If a user story conflicts with a previous story and means a previous story needs to be modified then waste is being created.

Liskov substitution princple

The Liskov substitution principle states that if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering the properties of the program.

While this doesn’t directly compare with user stories, I feel that user stories can often extend other stories. As in, build upon or modify existing functionality. When creating user stories that do this, it may be helpful to keep the Liskov substitution principle in mind. By thinking if the modification in the new user story will alter or conflict with existing functionality, unpredicted and undesirable side effects may be avoided. That isn’t to say that changing functionality is a bad thing, just that as you move towards more granular user stories, taking a step back and thinking of the wider user story can be useful.

Interface segregation principle

Its better to have many specific interfaces than one large general one.

By following this principle, code can be much easier to read as the smaller, specific interfaces are much better at conveying the intent of the code over a large interface with many methods that might not even be used. Furthermore, the increased coupling that will come from a large interface will make the software less flexible.

Larger user stories can come with the same issues as large interfaces. When there are multiple requirements the intent of the story can become confusing. Smaller user stories better convey the intent, and will be easier to assess if the desired value has been achieved.

Also, smaller and separate user stories have less chance of coupling the solutions together. Much in the same way as to pass a unit test you should do the smallest amount necessary, you should also do the smallest amount needed to get the value from a story. If more requirements arise, these should form new user stories.

Dependency inversion principle

Dependency inversion means that high level components should not have dependencies on lower level components. This inversion can be achieved through abstracting the lower level components behind interfaces.

While user stories don’t have dependencies in the same way that a class can, I think it could be helpful to ensure higher level user stories don’t have reference to and depend on lower level stories. For example, a user story for a new checkout form to increase conversion wouldn’t need the details of a lower level story for the email validation on the form. If it did, it would be over complicating the form story and slowing down getting value. However the lower level story would obviously need to have knowledge of the higher level story.

SOLID User Stories?

After thinking how the SOLID principles can be applied to user stories I can’t see them becoming the new standard to assess user stories anytime soon. However, thinking of why the SOLID principles are useful has definitely made me think more about what makes a good user story and how I can improve ay I write in the future.