INVEST in good user stories

A couple of months ago, I walked the Vision Tasks team through an agile maturity matrix — like a kind of agile health check — to give me an idea of where they were on their agile journey and highlight areas to focus on. One area was in the use of the acronym INVEST when working with user stories.

This post looks briefly at what user stories are and how the INVEST acronym can help.

Continue reading INVEST in good user stories

Sprint planning in Scrum

At our last retrospective, the Vision Tasks team decided to restructure our sprint timetable. With our two-week sprints running from Monday to Friday, it felt disjointed holding the end of sprint review and retrospective on the Monday morning of the new sprint; sprint planning was then squeezed into a one-hour slot on Monday afternoon.

With the new timetable, the sprint review and retrospective are now held on the afternoon of the last Friday of sprint. This should help us round off the sprint nicely without the hiatus of a weekend. But it also frees up the whole day on the first Monday of sprint for planning, which is what I want to explore in this post.

Planning in two acts

During sprint planning the team is asked to answer two questions:

  • What can be delivered during this sprint?
  • How will this work be achieved?

These don’t need to be separate meetings but what is important is that both questions be answered: what then how.

In my experience, new teams often only answer the ‘what?’ They drag enough stories onto the sprint backlog to match their velocity then kick-off the sprint with no real sense if what they have committed to is achievable or not.

The ‘how?’ part takes all the Scrum values to work at and perfect: commitment, courage, focus, openness, and respect.

Preparation

There are three things required going in to a sprint planning meeting

  1. a refined, prioritised backlog.
  2. an understanding of the team’s velocity, that is how many story points a team can complete in a sprint.
  3. an understanding of the team’s capacity for the next sprint, in hours.

Capacity

When working out the team’s capacity for development work, each team member should take the total number of hours for the sprint (number of days × hours worked, e.g. 10 × 7 hours) minus any time spent in meetings (daily scrum, backlog refinement, sprint review, sprint retrospective and planning).

Then deduct an hour or two of ‘slack’ for each day to account for dealing with email, distractions, requests from other teams, etc.

Timebox

The Scrum Guide sets aside a maximum of eight hours for a one-month sprint with a recommendation that shorter sprints are proportionally shorter. So, around four hours for a two-week sprint.

Part 1: What can be delivered during this sprint?

During the first part of the meeting, the product owner presents to the team the next-highest priority items on the backlog. Using the team’s velocity as a guide, the team estimates how much work they think they can deliver during the next sprint.

It can be helpful to keep an eye on the team’s definition of ready to determine whether stories are ready to be pulled onto a sprint, and the definition of done to be clear about what will need to be done to deliver it.

If any new information or insights have come to light, this is the last opportunity before the sprint starts to re-estimate any stories.

Part 2: How will this work be achieved?

Where I have found many teams go awry is that they have misunderstood the Agile Manifesto’s statement about “responding to change over following a plan” to mean “don’t have a plan”. It surprises them to learn that actually more planning is asked of them.

User stories, remember, are not requirements. While they represent user requirements they don’t document them. They are reminders to have conversations to figure out what needs to be done and how to do it. That conversation starts in backlog refinement and gets continued in this phase of sprint planning.

“To acquire confidence in what it can get done, many development teams break down each [user story] into a set of tasks […] The development team then provides an estimate (typically in hours) of the effort required to complete each task. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get the features done.”

— Essential Scrum by Kenneth S Rubin (Addison Wesley, 2013)

It’s up to the team how they do this but each story should be examined one by one, tasked-out and estimated in ideal hours. You may wish to break the team up to focus on particular areas of speciality, or you may wish for the whole team to discuss everything.

There are many benefits to this approach.

First is the wisdom of crowds. Because everybody is invited to contribute their experience and insights into every story, each story benefits from the input of the whole team about how that feature will be built, tested and delivered.

Newer team members get exposure to parts of the application they may not have encountered yet and can ask questions for clarity.

In thinking each story through at a deeper, more practical level, it can reveal things that had not yet been considered. There might be a realisation about the order certain stories need to be worked on. Anything useful that comes from these discussions should be recorded on the card so they are not forgotten.

Because every team member has helped think through every story, if someone unexpectedly goes off sick, other team members can step in to take up the slack more easily.

It is also easier to manage team capacity at this point than during the sprint. Once stories have been tasked-out and estimated in ideal hours the team can figure out who would be best suited for each task. The duration of those tasks then gets deducted from the team members’ capacity totals until there is assurance that everyone on the team has enough work to do during the sprint.

If there is clear shortfall or over-commitment, then the sprint backlog can be adjusted as appropriate: push items back onto the backlog or pull over more, break them down and estimate them.

At the end of this phase of the whole team should be clear about what the sprint goals are and how they will be realised.

Vote

The final ceremony during the sprint planning meeting is for the team to vote on how confident it is that it will deliver its commitment. This can be done using Planning Poker™ cards or simple finger-voting, showing one, two, three, four or five fingers depending on one’s level of confidence.

If the team are confident they can deliver everything the sprint begins. If not, they can explore why and make adjustments as appropriate.

Things will change, the team will discover things they hadn’t considered or couldn’t see at the time. Some tasks will be harder than they expected. Others will be simpler. But by taking the time to work together to plan as far as they can see, they set themselves up well for success.

Originally published on the Vision internal blog.

Let’s talk about mental health

The Firth of Forth, looking towards the Isle of May

One year ago today, I walked into work and burst into tears. I didn’t even make it to my desk. I felt the anxiety rising as I approached my office building. By the time I reached the top of the stairs I was shaking and hyper-ventilating. I walked past my office, sat in my boss’s office and wept.

Continue reading Let’s talk about mental health

Simplicity and maximizing the work not done

Photo by Klemen Vrankar on Unsplash

The other day in a meeting, I quoted one of the statements in the Agile Manifesto.

“Wow! Do you know the Agile Manifesto off by heart?” they asked me.

To be fair, not including the 12 principles, it is only four sentences long but I joked that I read it every night before I went to bed. I mean, obviously I don’t… it’s every second night.

The last few times I’ve read through the Agile Manifesto principles, though, one of the principles has grabbed my attention. It’s not one that gets too much attention. It’s this one, number 10:

“Simplicity—the art of maximizing the amount of work not done—is essential.”

Simplicity

Simplicity is big at the moment, which isn’t much of a surprise given how complex and complicated modern life is. Look at the attention people like Marie Kondo and The Minimalists are having.

A couple of years ago, I sat down and wrote a number of goals for my life, how did I want to live my life? The first item on that list was to live a simpler life. “Live a simple life,” I wrote, “Be aware. Live in the now. Observe yourself. Be kind to yourself. Love yourself and those around you. Slow down. Observe. Be curious. Go deep.”

Simplicity is good for development teams too. There are maybe things here that we can apply to Scrum teams.

One of the reasons that agile teams employ user stories rather than detailed requirements documents is that user stories promote simplicity. User stories are reminders to have conversations. User stories encourage us to leave some decisions as late as possible.

By focusing on the ‘why’ of a particular requirement, the team is encouraged to ask questions to get to the heart of the problem, rather than blindly following a checklist of requirements.

Slow down. Observe. Be curious. Go deep.

By focusing on the ‘why’, teams are encouraged to build what the customer needs as simply as possible and then iterate until the customer is happy.

Be aware. Live in the now. Observe. Be kind.

Simple code will have fewer bugs. Simple code is easier to understand later. Simple code that solves your immediate problem is better than complicated code that future proofs your application for scenarios that may never happen. Simple code is cheaper.

Maximize the amount of work not done

Let’s follow an example. Imagine that your customer says they need you to build them a car. So you gather all the requirements and you get to work. A year later, you present them with a car. It is a work of engineering genius. It has everything they dreamed of when you quizzed them about it 12 months ago. It has heated seats, a heated windscreen, a massive car stereo, eight gears, seven seats and has an enormous amount of storage in the boot. Brilliant!

Except, you learn that your customer only needs it to transport themselves the 17 miles from St Andrews to Dundee, on a daily commute with minimal luggage, and only during the summer. So they have waited a year to get something that is over-specified and over-engineered for their needs.

Let’s restart this scenario and write a user story to capture why the customer needs a vehicle.

As a commuter I want a method of transport that will enable me to travel the 17 miles from St Andrews to Dundee so that I can travel to my work (Monday to Friday) during the summer.

(Ignore that I’ve included some acceptance criteria in the user story to speed things up here.)

The engineers think, it sounds like they could do with a car but what if we start simply and first build them a pedal bicycle?

It takes them two sprints and deliver the bike to the customer. After four weeks the customer has something usable. They try it out. It does the job but it takes them 90 minutes to cycle to Dundee.

“Hmmm… could I have something a little bit faster, please?”

The engineers discuss it, agree that it still sounds like they could do with a car but what if we just motorise the bicycle and create a scooter?

Three sprints later (6 weeks) they deliver their scooter to the customer. The customer tries it out.

“This is brilliant! I can now do my commute in 40 minutes, and I love how I can weave in and out of traffic! I can use a pannier for my briefcase and wear waterproofs if it rains. I thought I was looking for a car but I’m really happy with this solution, let’s stop here.”

By thinking simply, the engineers have delivered a solution the customer is happy with in just 10 weeks, rather than an over-engineered solution that they had to wait 52 weeks for.

Example

I remember when I was the Assistant Web Manager at the University of St Andrews working on some JavaScript code. I had a form validator to build that required a number of libraries. I got it working in a couple of days and was really pleased with it.

But I didn’t leave it there. I could see its potential, how this solution might be used throughout the website. So, I refactored my code to make it easier to use with other forms and included it within our core JavaScript file that loaded on every page. I wrote some code to detect whether such a form was on that page and if there was then it dynamically pulled in the required libraries. I was delighted with it. It had only taken me an extra three days. I deployed it.

Yeah… you’ve guessed it, we never used it again, anywhere else on our 300,000-page website. What a waste of three days; what a waste of money. If I had been aware of the Agile Manifesto principle “Simplicity—the art of maximizing the amount of work not done—is essential.” I would have stopped and deployed after two and moved on.

Over to you…

What would benefit from being thought of more simply in your product? What would benefit from having less work done?


Originally published on the Vision internal blog.

Version numbering schemes: an observation

It’s funny the things you notice when you’re new to a place, but one of the things I’ve noticed is the inconsistent version numbering schemes that are in use across the Vision products.

A quick search through our internal documentation reveals that we currently use at least five different version numbering schemes:

  • Major only, e.g. ApplicationName 10490 or TLA 720.
  • Major.minor, e.g. ApplicationName 3.2 or ApplicationName Tango 2.6.
  • Major.minor.patch, e.g. ApplicationName 1.4.0.
  • Major.minor.patch.build, e.g. ApplicationName 1.0.0.0 or ApplicationName 2.2.1.1.
  • Year-based, e.g. ApplicationName 2019.11.

I wonder why there are so many different numbering schemes. I expect, like many of these things, it has simply grown organically without much planning.

Semantic versioning

While there are many different ways of numbering software versions, one of the most widely adopted version numbering schemes is semantic versioning. It is also my favourite thanks to its predictability.

At its simplest, semantic versioning uses three numbers:

  1. MAJOR version — increased when you make incompatible API changes.
  2. MINOR version — increased when you add new, backwards-compatible functionality.
  3. PATCH version — increased when you make backwards-compatible bug fixes.

Using this versioning, you can easily see, for example, that v1.4.1 will offer the same functionality as v1.4.0 (or v1.4) but with bug fixes. Whereas v1.5.0 will add new features that are backwards-compatible with v1.4.0. v2.0.0, on the other hand, will make significant changes that are at least partially (if not completely) incompatible with the v1.x.x software.

Benefits of a consistent numbering scheme

The most obvious benefit of using a consistent numbering scheme across an organisation, particularly one like semantic versioning, is that at a glance you can see what has changed in a release. A version number helps manage expectations.

When you have close software dependencies, as we do, it becomes incredibly helpful when planning releases.

Imagine looking across the product roadmap and seeing that the database system your own application relies on is anticipating to bump up from v1.5.0 to v2.0.0 in three release cycles’ time. That gives you an immediate heads-up that there are likely going to be significant changes to that system that will require work on your own product. There are now conversations to be had and work to be scheduled into your own up-coming sprints to anticipate this.

Conclusion

Like I said, this is just an observation. But as we move forward our inter-dependencies are likely to deepen. It might be beneficial to address this inconsistency sooner rather than later.


Originally published on the internal blog. I’ve edited a few of the details for this public version.