End of April, and we are diving deep into the Skillsforge project – and other things we can’t share just yet.
Stuart and Susie are leading our move to Skillsforge, and understanding the needs of users is paramount. To that end, Stuart is writing this week’s blog:
We have been having discussions within the team about how to manage user stories and in particular technical tasks. User stories are important as in our agile environment as we don’t have a large formal requirements document that documents every feature we are implementing, rather we manage requirements iteratively through a backlog of ‘user stories’. These user stories capture a description of the software feature from an end-user perspective that delivers business value.
James shared a blog post Why technical user stories are bad, which highlights the dangers of creating technical stories. In our environment, our projects are not generally developing new applications, but rather implementing COTS products and it seems to us that at times COTS projects do sometimes need technical stories. For example, when the vendor is setting up the test environment, there is no direct business value, but we will still want to track the progress in our sprints.
However, I would argue that we should still be careful when creating non-user based stories. We want to create user stories where possible as they will be used in testing. Most technical tasks can probably be linked to user stories. For example, “Configuring Single Sign on” seems on the face of it like a technical task with no business value, however if you think from the user perspective, you could write a story like ‘As a Skillsforge User I need my Flinders University logon credentials to automatically log me into the system so that I don’t need to enter my credentials every time I use the system‘
So perhaps the approach should be a ‘user story’ first approach and only create a non-user based story as a last resort.