Sprint 0 (or iteration 0) checklist … simple but not always easy

I am currently trapped in the real world … working on a real project rather than running a training course on how to run projects.

Interestingly it turns out the real world is harder and more ambiguous than the projects in my training slides 😦

Having said that though, the fundamentals don’t seem to change. We have stopped a project and are about to restart. It is really urgent and we have inherited a project whose budget (in time and money) has already been spent. So we really need to get going.

But are we better off starting or are we better off getting our act together before we start so we are not “mistaking activity for progress” by rushing off in the wrong direction?

What I say in my training courses is to get the team together and brainstorm everything that needs to be in place before we start.  Then prioritise these ideas using MOSCOW and spend your first iteration (or sprint) nailing those stories.  Then if you have not done all the “must haves” then don’t start and if you have not done all the should haves then you know your next retrospective will include “should not have started before …”.  But with your should haves you can turn them into risks or tasks to do in the next iteration or two by dropping some stories to make room for them.

Great, I can’t fault the logic, but now I am in the real world and the development team is already off and running on some of the things they know need doing for our first urgent release, while some of the team are yet to arrive on site.

So here are the must-have’s I am applying.  Let’s see what happens.

1. Do we know where we are going?
• Do we have a Mandate to do the project? Ie
• Do we know the problem we are solving (yes). 
• Do we have funding allocated and not just “soon to be sorted”. (Yes)
• Do we have a complete backlog that the whole team understands (no).  Eek … do we know what to do for the first release? (Yes – we need to be ready to integrate some functionality for the other key project by the end of next month.
• Do we know our scope and priorities? (Yes-ish, er that is to say roughly yes) [which is probably the most dangerous answer of all].  (But we do know the scope for t he release in one month and we know our first priority is to hit that deadline subject to our other first priority of sufficient quality is mandatory).
• Have we defined success? Do we know what “good” and “fixed quality” actually mean? When is a story done? What non-functional requirements need to be meet to release? (Er No we are not really clear yet)
2. Do we know how to get there?
• Do we know what practices we are using? (Yes – we are stealing them from the project we need to integrate into).
• Really? Do we have planning and showcase meetings booked (yes). Do we have retrospectives and standups? (Yes)
• Do we know what technologies we are using? (Yes, except for some of the bits).
• Do we know who is doing what on our project? (We have a sponsor, a product owner, a scrum master, a BA, some developers and a project manager). Again – Do we know who is doing what? (They should do, they know their job titles, except the Scrum Master, I am not sure if we told him that he is on the project to the bitter [or joyful] end). In other words – We need to be clear on what they actually do. Cool – do we have an architect and a tester? (Long pause … oops)
• Do we have a test strategy that is understood by the whole team? (No).
• Do we have a publicly available risk register? (No but the PM is listing and discussing the key risks)
• Do we have a high level architecture that is understood by the whole team (coding standards if we want them, standard tools, guiding principles and of course a big picture on a wall or whiteboard of the context diagram and dataflow diagram (or domain model or strawman or something). (Yes-ish)
• Do we know the biggest constraint that is likely to inhibit our success? (Yes and no)
• Do we know the few things that really need to be done well and the other things that need to be done well enough to succeed? (sort of) What has to work for us to succeed and what has to be done really well? What will be forgiven and what will be remembered after the project is done? (er … yes)
• Do we have a road map of what is being released in what order, say epics per release? We have lots of stories and epics in Sharepoint, Jira and Version One. But we do know what needs to be done for the end of the month and we are consolidating to one backlog in the coming days)
3. Are we set up to succeed?
• Do we have the right people? (yes)
• Have we moved to one location (No – same planet but different countries)
• Have we cleared the decks of all other distractions (no – some of the core team are on other initiatives)
• Do we have real buy-in and trust from both the team and the business stakeholders (yes)
• Have we all worked together before (no)

The trainer in me is screaming stop. The enthusiastic optimist in me is calmly saying we have been here before and the crew is a good one so we will pull it off.

But the project manager in me is comparing risks against each other to pick the least worst (or should I say best) options. (I am not the PM on this project but I will sink or swim with him so my inner PM is talking loudly in my head).

So here is my current cunning plan:

• Get the test strategy in place before anything else.  Then make sure we have a technical scope and high level architecture diagram that we can show both the related project and the business customer.
• Define Done, Quality and the “what do you really do” part of the key roles
• Break the project into “imminent release” and “rest of project” and get on with some of the imminent release while sorting the rest out.
• Smile and look confident while copping a schalaking from the sponsor for not being fully ready.  Calmly repeat “its better to be unhappy now than at the end of the month; It’s better for the team to commit than to force them forward before they are ready; We know the biggest constraints and we are focussed on managing them first; stop hitting me, its not really appropriate).
• Expect to only deliver one quarter of my potential velocity in sprint one because I am really doing sprint two late.  Maybe I should delay to sort things out but that always seems to rub me the wrong way.What

What would you tell me to do?