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

Testers Guide to Myths of Unit Testing

One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively.

Also, I want to do a talk about it, so I figured I would test the premise, see if potential audiences were into it. I put this on Twitter:
Working on a talk about what testers might believe about unit #testing & how we interact with developers creating unit tests. Any challenges/additions for my list below? #development#agilepic.twitter.com/4oT5HE4qs3 — Ash Winter (@northern_tester) December 19, 201730 replies with ideas tends to indicate that people might be into it. 
The ListI thought, as my final blog of 2017, I would provide a super useful list of the myths and legends we as testers might believe about unit testing:
That developer…

Wheel of Testing Part 3 - Applications

I've only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on...

After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I've explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I'm not sure how many get used. I am inspired by models such as the "Heuristic Test Strategy Model" by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:

Helping to unlocking a career in testing which may be stuck

It is no…

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…