Skip to main content

I believe in Sprint Zero....


You want to do what?

‘There’s no time.’ That’s what I always hear. ‘There’s a date to hit.’ That’s another good one. When I raise an eyebrow and say ‘there’s always a date to hit’ it’s not just a consultancy mantra. I know a secret about project dates. They move. Slippery little blighters they are. Reality storms in and changes the game. I don’t know anyone who hasn’t experienced this, yet it remains a secret. So, there’s no time to think, let’s build.

Now that we’ve established there is no time for a Sprint Zero, I’ll start by communicating what I believe is a reasonable explanation of what a Timebox or Sprint Zero actually is. I generally go with ‘a protected time for the team decide how to work together, find out why the product needs to exist and a basic idea of what needs to be done in the near future’. If I’m not feeling particularly verbose then I’ll just call it ‘a team based starting point.’

The order in which I say these statements is important (to me) as the success of your endeavour has its basis in first the how (communicate and iteration), the why (the real business value) and finally the what (how do we go forward initially). Note the word ‘initially’, this can, will and probably should change. Funny how when someone says risk they actually mean fear of change and vice versa, that, is probably a whole other topic.

Its all about the community....

The foundation of a Sprint Zero for me is the challenge of beginning to build a team. Some organisations are finally having the hallelujah moment where soft and hard skills are equally valued so I’d like to stick with that happy thought. So you have a team of multi-skilled ‘developers’ (used in the holistic fashion), they are going to be together for a while so they need to rub along in an efficient manner which promotes business value driven, robust development. 

The first thing to consider is buy in. How can we convince the sceptical among us that two weeks of ‘team building’ (as they may see it) is a worthwhile exercise? On an experienced based note the ‘sell’ will be infinitely harder in organisations which are currently transforming to agile methodologies. This is always juxtaposed with previous behaviour, where an organisation will spend months preparing for a waterfall project but two weeks for a Sprint Zero is too much to ask. 

Understanding who needs to buy in is the key. You will need to consider both the team and other stakeholders. Primarily if the team doesn’t understand why it wants to embark on a two journey of practical and conceptual discovery then it will be difficult to explain it to anyone else.

The team should need a Sprint Zero and demand it of their organisation. It is their chance to understand, explore, ask big questions and implement before the project begins in earnest. 

Some teams will want the practical benefits of a Sprint Zero. For example the team do not want to implement their Backlog storage tool during the first/second/third Sprint. The team should not find out that they don’t have database permissions when they begin Sprint One and wait two days for Service Desk to sort it out. Some teams will be sold on the conceptual benefits. How do we interact? What are expectations/promises to each other? How do we define our relationship with the business?

Every team is different, its a blending thing......

Each team is usually somewhere in the middle and desire a mix of the practical and conceptual. I would recommend a 50/50 split, too practical and the team will struggle to engage with each other and the wider stakeholders once the project begins. Too conceptual and the basic building blocks are not there to begin with, leading to a stuttering first Sprint.

Other stakeholders bring their own layer of complexity plus their own agendas. Business or project management stakeholders might see agile development as a means of getting a project started quickly and seek to circumvent the Sprint Zero process. This can be as a result of an agenda or just a fundamental misunderstanding of the methodology in use, either way if your team is bought in to the idea then you have a much better and (more united) case to take forwards. 

Don't fool yourselves........

The main selling point is that, eventually we will need to do most of these things along the way anyway. You will need to invest this time, whether you like it or not. As with most project and/or team based decisions, you can either choose to do this in a controlled fashion when it gives the most value, or in a piecemeal fashion over the course of many Sprints, directly impacting your velocity.

How long?

In conjunction with the buy in will be the decision on how long you will spend on your Sprint Zero. I would recommend no longer than the length of a normal build Sprint. Teams can wallow in a Sprint Zero, especially those whose organisation who is in agile transformation, the desire to know more and more before beginning can be overwhelming. I have seen recent examples of teams in this state for 6 weeks, iterating over their Backlog again and again and again. Iterating while not moving forward is tantamount to procrastination, as no new information exists to change your train of thought. We should ask ourselves as a team, what, to us, is the most valuable content for a Sprint Zero in the context of this project?  

There are three main threads to consider when determining your Sprint Zero content, let’s stick with our How, Why and What theme:

How?

I further split the How into four areas, to be noted that this is not an exhaustive list:

Roles
Experience tells me that when a team faced with a certain type of situation displays hesitant behaviour, they are unsure of their role, its boundaries and where primary responsibility lies. Primary responsibility is often neglected, statements like ‘we all own the Product Backlog’ generally translate as ‘no one owns the Product Backlog’. Avoid this trap. Spend time exploring, educating and setting expectations.

Communication
Whether you are embarking on a software project or working on a fishing boat (as a random example) communication will always be the greatest challenge you will face. In this context consider how your team will manage the ten percent of the Sprint dedicated to the Product Backlog and its refinement and understanding. An effective strategy here will serve as an enabler for the team to collaborate with each other and the wider business.

Iteration
The team should consider how it iterates through the work it will commit to. What are the daily, Sprint and release cycles? How does work flow between analysis, programming, testing and release and back again.  Considering how you size and estimate will affect how you iterate. There is no right or wrong here. I choose story points as I consider ideal day’s too literal, therefore lacking subtlety and flexibility.

Artefacts
Different methodologies demand different artefacts. Scrum allows you to scale up the number and range of artefacts that you use whereas other methodologies demand more. Prior to embarking on the journey decide which artefacts you desire and who has primary responsibility for them. A Product and a Sprint Backlog are a given but you may include a Risk Register, Impediments Log and so on.

Why?

Engagement
Without an understanding of why a product needs to exist a team will struggle to engage over a significant period of time. The main reason for building may well be that the organisation is being paid to do so. Is this enough to instil a sense of belief in the team that what they are doing is valuable? Ask the question. Once you have had a high level project briefing with the team and stakeholders ask if they know why and what value the product will provide. Mere money may not be enough.

Trust the team with the commercial value
Along the same lines is letting the team into the inner sanctum of the project. What are the terms under which they will be working? What is the Time vs. Cost vs. Functionality vs. Quality model? Many projects are conceived based on a flawed model to be utilised in an agile project where time, cost and functionality are fixed and quality is the variable. Knowing these terms and being trusted with them is enlightening and empowering for a team.

What?

As with the How, I again split the What into 4 areas:

Prototyping
Building a simple prototype can drive out an early spiky area of development. Have tricky architecture you’ve never worked with before that you need to push data through? Build something that pushes a random number through. Have a User Interface you aren’t too sure about and need feedback on? Brainstorm, mock up and demonstrate to your users.

Approaches
This is as much commitment based as methodology based. If you want to use Test Driven Development, backed by automated builds, with exploratory User Interface testing and automated API testing, now is the time to consider. This commitment will also feed into your sizing and strategy for iterating over slices of the product. It can and should change over time.   

Environments
This is one of my true favourites as the simplicity of it makes me smile. A project (that had no Sprint Zero) I worked on decided to use a particular environment which suited our needs. However after launching headfirst into the build phase we actually found out that it didn’t work. 10 days of heartache and a failed Sprint later, we had to abandon it. A simple Sprint Zero smoke test would have found the fundamental problem and saved an entire Sprint of development.

Product Direction
This aspect is entirely project and context dependent. However, let’s aim for a few things in terms of direction. Firstly let’s have a starting point, a first Story to tackle which displays real business value. Secondly have the first set of stories and features prioritised and the first release nominally planned, primed and ready for change when the real velocity comes out during build. Thirdly, have the bigger future epics in the Backlog and sized, even if it is hundreds of points. Once they are in they become real to the team.

You might need to battle for it....

As with most truly valuable project and team activities a Sprint Zero is worth fighting for and it is a belief that I carry with me to the organisations with which I work. That is not to say my advice is always heeded, sometimes the urge and pressure to build is too much for the team and project to bear.

Truly successful agile teams and organisations see that a Sprint Zero is not a nice to have but essential to the success of the project. Those who receive this time in a protected state and make good use of it give themselves a firm foundation to evolve and change from.

Comments

Popular posts from this blog

A Lone Tester at a DevOps Conference

I recently had the chance to go to Velocity Conf in Amsterdam, which one might describe as a DevOps conference. I love going to conferences of all types, restricting the self to discipline specific events is counter intuitive to me, as each discipline involved in building and supporting something isn't isolated. Even if some organisations try and keep it that way, reality barges its way in. Gotta speak to each other some day.

So, I was in an awesome city, anticipating an enlightening few days. Velocity is big. I sometimes forget how big business some conferences are, most testing events I attend are usually in the hundreds of attendees. With big conferences comes the trappings of big business. For my part, I swapped product and testability ideas with Datadog, Pager Duty and others for swag. My going rate for consultancy appears to be tshirts, stickers and hats.

So, lets get to it:

3 Takeaways

Inclusiveness - there was a huge focus on effective teams, organisational dynamics and splitt…

Wheel of Testing Part 2 - Content

Thank you Reddit, while attempting to find pictures of the earths core, you surpass yourself.
Turns out Steve Buscemi is the centre of the world.

Anyway. Lets start with something I hold to be true. My testing career is mine to shape, it has many influences but only one driver. No one will do it for me. Organisations that offer a career (or even a vocation) are offering something that is not theirs to give. Too much of their own needs get in the way, plus morphing into a badass question-asker, assumption-challenger, claim-demolisher and illusion-breaker is a bit terrifying for most organisations. Therefore, I hope the wheel is a tool for possibilities not definitive answers, otherwise it would just be another tool trying to provide a path which is yours to define.


In part one, I discussed why I had thought about the wheel of testing in terms of my own motivations for creating it, plus applying the reasoning of a career in testing to it. As in, coming up with a sensible reflection of real…

The Team Test for Testability

You know what I see quite a lot. Really long-winded test maturity models. 

You know what I love to see? Really fast, meaningful ways to build a picture of your teams current state and provoke a conversation about improvement. The excellent test improvement card game by Huib Schoots and Joep Schuurkes is a great example. I also really like 'The Joel Test' by Joel Spolsky, a number of questions you can answer yes or no to to gain insight into their effectiveness as a software development team.

I thought something like this for testability might an interesting experiment, so here goes:

If you ask the team to change their codebase do they react positively?Does each member of the team have access to the system source control?Does the team know which parts of the codebase are subject to the most change?Does the team collaborate regularly with teams that maintain their dependencies?Does the team have regular contact with the users of the system?Can you set your system into a given state…