Softwire Blog
6 Key Factors for Successful Sprint Planning
24 March 2017, by Helen Hosein
Picture this: You’re leading a talented, cohesive, high-performing team of software engineers. They work as consistently and predictably as a beating heart. Every sprint planning, you pick the next eight stories off the top of your perfectly groomed, prioritised backlog, knowing that in two weeks’ time, those eight stories will be delivered in production, and your team will be ready for eight more. Sound familiar? No?
If you’ve yet to achieve ‘scrumvana’, then your team probably has a variable throughput. This is particularly likely if you’ve got a new team, or are setting up a new project. Until you’ve had time to settle into a cadence of delivery, it can be difficult to predict how much work your team can get through in a two-week sprint. So how do you plan? How many stories do you assign to a sprint if you don’t know whether you’ll get through two or ten?
Plan conservatively
Start by identifying a minimal nugget of work that your team can reasonably get through, based on your team’s capacity. Even your most pessimistic team members should agree, “If we can’t get through this by the end of the sprint, something is horribly wrong.” That will give you the best chance of delivering your plan, keeping your stakeholders happy, and leaving your team with a sense of accomplishment. It also gives you an early warning system: if you can’t deliver that minimum amount by the end of the sprint, something is horribly wrong. You’ve made some bad assumptions about the project, which you need to investigate and fix.
Far more likely, you’ll get through at least that minimal amount. So what do you do with the slack?
Set some stretch goals
When you identify your minimal nugget of work, you should also identify a few stretch goals for the team that will keep them busy if (or more likely, when) they’re done with their main goals for the sprint. Make sure it’s clear which stories (or other tasks) are stretch goals and which are the main goals – your overall project plan shouldn’t depend on getting your stretch goals done this sprint, and your stakeholders shouldn’t be counting on them. There should be absolutely no shame in carrying them over to the next sprint if they’re not done yet. Your team should also be aware that they’re lower priority than the main goals. Stretch goals are like dessert. You’re not allowed to touch them until you’ve finished your mains.
Eliminate unknowns
A lot of the variation in throughput at the start of a project is because there’s so much unknown. There are problems you don’t know how to solve yet – you may not even know whether or not they’ll be problems yet. Planning in spikes in your early sprints can shed light on those unknowns to make things more predictable. Use your early spikes to test your riskiest assumptions, and also to identify and solve the problems that could slow down your first few stories. With those answers in hand, you can increase your confidence that the next sprint’s worth of work will be appropriately sized and free of blockers.
Later in the project, there will naturally be fewer unknowns, so you won’t need to do as many spikes, but you should still plan them in where appropriate throughout your project to make sure the next batch of work is sufficiently well understood. Always plan a spike with a clear set of objectives – it should be answering a specific question that will then help to refine and break down an upcoming story. Remember to factor in the time your team will spend on spikes when you’re working out your capacity for story work.
Keep measuring and improving
At any phase of your project, you should always be on the lookout for ways to improve. It helps to focus on whatever is the biggest challenge the team is facing at that point in time. At the beginning, variable throughput may well be a big issue. To help you improve, you may want to use a Kanban board to visualise the flow of work so you can easily see where the bottlenecks are. Keeping an eye on cycle times and then investigating what’s slowing you down (or speeding you up!) can also lead to improvement. Use data to find the root causes of variation, and work with your team to address them. Make continuous improvement a habit, so when your throughput settles down, you can tackle the next challenge.
What about bugs?
If your throughput is not yet stable, your flow of bugs is unlikely to be stable either. That can make it hard to predict how much capacity you should allocate for bug fixing each sprint. Again, start by planning conservatively – assume the worst and make sure you have enough capacity to fix loads of bugs if needed. You can always fill the slack with stretch goals if there aren’t as many bugs to fix.
In the meantime, work towards building quality into your stories. Shorten your feedback loops by doing things like running an automated regression suite on each commit. Avoid writing bugs in the first place by conducting good code reviews, or using pair programming. Any bugs associated with a story should be fixed or avoided as part of the process of getting that story to done. Then, bug fixing won’t be a separate process you need to plan for – planning a story will inherently include bug fixing around it.
What about tech debt?
Just as you may need to devote some capacity within a sprint to spikes, you may also want to devote some to resolving tech debt. Remember to time-box any investigatory work, and adjust the output you expect from your team to account for the time they’ll spend on it. Tech debt tasks should be well-defined and broken down, just as you would stories, to help you maintain your cadence. Then you can schedule those tasks into your sprint the same way you would do with stories.
And finally
Capacity-based sprint planning can be a useful fallback to get things going when throughput is variable. Eventually your team will settle into a more predictable cadence, making it easy to plan based on throughput alone. Make sure you keep measuring and improving so that sources of variability don’t creep back in. That way, you can keep that rhythm of delivery beating for the life of the project.
What I did on my volunteering day – Jenny
20 March 2017, by Jenny Mulholland
I had the privilege of being part of the Inspire! iDiscover week at Carlton Primary School in Gospel Oak.
Inspire! are an Education Business Partnership working in Hackney, Camden and Islington. They enable young people to learn about work and gain practical experience of the skills and attributes they need for employment, in particular working with young people from less advantaged backgrounds or who are at risk of being excluded from mainstream education or who are not in education, employment or training (NEET).
iDiscover is an initiative which introduces Science, Technology, Engineering and Mathematics (STEM) careers to local primary school children. The week-long programme provides schools with work-related STEM activities with the aim of encouraging more girls and non-white students to consider a career in these industries.
I was part of an afternoon session with two Year 1 classes where they get to meet real-life people working in engineering careers. Aside from me, there were people from the Institute of Engineering and Technology, an energy engineering and consultancy firm, and an architect.
Each of the engineers ran short sessions with the children in small groups – things like building a torch or a Lego tower. I wanted to explain to the kids what a software engineer does in really simple terms (we give instructions to computers to make them do things) so I set up a very simple Scratch project. When the children pressed specific buttons on the keyboard they could make a cat sprite move around the screen, change colour or say hello to them, and I tried to get across the message that these were all instructions I had given to the computer to make it do these things.
Although some of them had never used a computer before they all got the hang of it pretty quickly and came up with ideas for other things we could make the cat do. They’ll learn more about Scratch in the later years of primary school but for now, I was just keen for them to learn that software engineering is another type of engineering, and understand that it has something to do with playing with computers!
In summary, I would like to think that I spent my volunteering day helping some kids take a small early step towards a STEM career.
Photos by Inspire! EBP
Advanced Clean Code
15 March 2017, by Chris Arnott
This post is a quick overview of patterns I have picked up over the years that I aim to use when coding and usually end up pointing out in code reviews.
These aren’t hard and fast rules, but to me, this post forms an extension to Uncle Bob’s clean code (which you should read right now if you haven’t already!).
Top CIO Priorities 2017 – Infographic
1 March 2017, by Karl Graham
