#sprint zero

[agileautomata]

Long Term Agile Planning

One criticism of Agile methodologies is that long term planning is neglected or, at least, runs against the grain. This may be an impression born out of a lack of deeper familiarity with Agile methods. Long term planning in the form of release planning is very prevalent in the ecosystem of agile methods and processes. Renown agile coach Mike Cohn has an entire chapter on release planning essentials in his book Agile Estimating and Planning. He defines release planning as “..the process of creating a very high-level plan that covers a period longer than an iteration.” and says the following about it: “At its simplest level, release planning is trivial: Multiply the expected velocity by the number of planned iterations and then select stories whose estimates sum to fill up the release.”

Or consider this excerpt taken from Essential Scrum by Kenneth S. Rubin: “If the term release planning doesn’t fit well with your organization’s practices, replace the terminology with longer-term planning or milestone-driven planning. Whatever you choose to call it, release planning in Scrum targets a future state when important variables such as date, scope, and budget need to be balanced. The basic timing, participants, and process remain the same regardless of the name.”

Nevertheless, many people still think that long term planning isn't useful or is a slide back into waterfall methods. But if you take a moment to think about it, a few things become clear. Any objection to long term planning could equally be an objection to sprint planning as well. One could argue, and some do, that the daily scrum is sufficient and that it doesn't make any sense to try and plan anything beyond the day. 

Some advocates of KanBan argue this very thing. I, for one, can not abide by this philosophy. I can not escape the maxim that a failure to plan is a plan to fail. To make no long term plans is to be ruled by the tyranny of the immediate. Only the very next thing that has been discovered will dominate a team's consciousness in this context and fire drills and heroics will dominate the day. 

Any sense of improvement and purpose cannot be sustained in this setting. As humans, we naturally see all things in the context of planning, purpose, and growth. We want to and expect to, travel a chosen path and arrive at some destination. Few of us can say we arrived where we thought we would but we arrived somewhere, nevertheless, and that destination was determined by each of the decisions made along the way. 

Let's review some of the concrete benefits of long term planning.

Capacity Planning. Knowing what's possible. You can’t put 10lbs of crap in a 5lb bucket. A feedback loop is created between the engineering team and the product owner thus informing them of what is indeed possible.

Measuring Impact of changing priorities. Seeing the impact of changing priorities. The cost of contact switching is a reality at an organizational level and not just at an individual level. Adding a few things here and there directly impacts what the team thought they could do several sprints from now. 

Cross Team Coordination. Giving the organization time to plan (marketing, finance, resources management). All major organizations need time for these. Not everything moves at the same speed. There are budgets and legal issues that need to be worked out. Proposals for more resources require time to get sorted out as well. 

Product Vision Alignment. It’s too easy to be driven by pressing stakeholders all vying for each of their desired features and lose sight of the product vision. Long term planning helps to highlight the actual values behind the product vision.

Contextual Awareness. If teams are to be self-directed and autonomous, then it’s imperative they are aligned on mission and possess a shared context with the greater organization. Cultivating a real sense of autonomy, personal responsibility, and sense of purpose will do more for team morale than any superficial perks ever could. See: Context over control

Having established that long term planning is both normative and valuable, what then are its characteristics? What exactly does it look like and how does it differ from the other established forms of planning? This is somewhat a trick question because long term planning in an agile context should share all the same characteristics of the other types of planning. 

The whole team is involved and drives the answer. This is not an exclusive product initiative made behind closed doors and presented to the teams

Works backward from a date (day, sprint, quarter) See: Yes, you should estimate

It is uncertain and subject to change.

[agileautomata]

Agile Planning Land Mines

The agile manifesto and its specific implementation in Scrum has revolutionized software development. In its original form, it prescribed the practice of basically two loops, cycles or increments. The one that we most frequently think of is the sprint. Typically a two week period in which a team seeks to deliver another working unit or increment of a product. But there is also another cycle that we don't typically think of and that is the day. 

Just as there are special ceremonies that attend the sprint, a retrospective looking backwards and a planning meeting looking forward, so in the daily scrum there is communication among the team about what was accomplished in the previous day and organization about what will be attempted to be finished in the day that lies ahead. So even though each of these loops has its own characteristics, they are not radically different.

This is even demonstrated in the classical diagram of the scrum process. I heard someone describe this diagram as the “snail with a tumor on its back” and I've had it in my head ever since. If you’re not sure what I’m talking about just do a google image search for “scrum development” and you will see it everywhere. It shows a large loop representing the sprint and a smaller loop on top of that representing the daily scrum.

Many die-hard adherents of the original scrum guide believe that this is all that is required to do good iterative software development and that any planning that extends past the sprint is blasphemy and, at best, a reintroduction of the waterfall development methodology. And yet the desire and demand for longer term planning repeatedly rears its head under the terms of release planning, sprint zeros, and product roadmapping. 

I believe there is a great secret here for us to discover because I don't believe that the desire for these longer term plans are unjustified nor do I believe they are anathema following the strict strictures and values enshrined in Agile and the Scrum process. Let’s look at each of these specific flavors of longer term planning and see where each fails and then examine what a truly faithful pattern of long term planning might look like within the scrum process. 

Firstly we have release planning. This presupposes that a release is larger than a sprint which, on the bare face of it already militates against scrums requirement that the conclusion of a sprint should be a potentially shippable product increment. That means, if we are being real with our language, that every single sprint should produce a releasable release. What’s more, the advances in continuous delivery (CD) have made it possible and desirable to deliver functional features multiple times within a sprint. It has reached a point where it is a bragging point to say that one’s team pushes to production multiple times a day. So we see that CD has kind-of made obsolete defining longer term planning efforts as release planning. 

Secondly we have the infamous Sprint Zero. This is defined as a period of time that scrum team uses to set up a project and plan the larger initiative related to what they are trying to build. While its name is very different, the desire behind it is not fundamentally different from release planning. It certainly can't just be planning for the next sprint because that would just be sprint planning and it’s also not just the first sprint of a new team because the teams that practice it do it on a recurring basis. The unfortunate part about this practice, and the area in which it is most routinely attacked is that it violates the principles of what a sprint is supposed to deliver. A sprint is supposed to produce a working product increment and a sprite zero makes no attempt to do so. It is to its creators credit that they did do their best to introduce this longer term planning that everyone wants in the terms already being employed by the scrum framework. They repurposed the sprint increment and just defined this sprint as a special case. Another unfortunate side effect of this is that longer term planning does not typically require an entire sprint to do so not only do we have a sprint without the required properties of a sprint but it's also not even the length of a sprint so now we find ourselves just using terms to fit things in. 

Lastly we have Product Roadmapping. Unhampered by any desire to abide by existing scrum practices, this kind of longer term planning is typically done without any of the development team's involvement and sees itself has happened completely outside of the existing scrum loops. It's kind-of seen as a byproduct of a teams product owner working with other existing business stakeholders to produce a long term vision that will be either delivered to the team in a big reveal or either metered out to them in the form or backlog items. The difficulty with this is that it is not possible to get estimates of any of this work without the team. So there is no road map. There may be a list of desired features but there can be no roadmap without estimations and no one can estimate the work but the team. 

So to conclude the quandary in which we find ourselves, if releases are obsolete in release planning and “sprint zeros” are no sprints and all and a misuse of the sprint term, and product roadmaps give us no real roadmap, where do we go? 

In future posts, I’d like to describe a practice of long term planning that subscribes to the strict principles of the iterative method, does not bastardize any of the established existing scrum artifacts and activities and, further, expands upon the philosophy and fundamental mechanics of scrum. 

I believe that, as we dive into this subject with greater care, you will not only be confident and empowered to do longer term planning in a truly agile way but that your understanding and appreciation of the existing scrum practices will be revolutionized as well. 

[projectmanagementopenschool]

Taller: Implantación del Sprint Zero

El próximo sábado por la mañana tendremos un taller práctico en el que aprenderás cómo iniciar proyectos en Scrum

Los sistemas de gestión ágil, como Scrum, se caracterizan por un ciclo continuo de producción, lo cual tiene en general un aspecto positivo pero no da lugar a una “inicialización” del proyecto, en la que se pueda formar el equipo y dotarle de los recursos necesarios para su trabajo. Aquí es donde entra en escena el Sprint Zero. La idea de tener un primer ciclo de trabajo en el que se ponen los…

View On WordPress

[digitalturtleblog-blog]

Sprint 0: What is it for and should it exist?

Many people new to agile will hear of having a “Sprint 0” and wonder what its goal and activities should be. Indeed many agile practitioners would say it shouldn’t exist, and you’ll often see comments online saying something along the line of it being a construct introduced by senior management used to cling on to waterfall ways of working.

Let me start my saying that the latter statement is a wholly unfair criticism and generalisation of senior management that has no logical basis. Why should an “old dog” in senior management be less capable of embracing agile than a “young pup” fresh out of university and eager to learn. On the contrary, the ability to recognise the need for change and adapt is a key ingredient in good senior management.

I think everyone would agree that prior to kicking off the Sprint 1 planning session, it’s helpful to have:

A high level technical architecture for what you’re building

A definition of done

Some basic epics or stories to get things rolling

Licences and tooling for the team

Environment and CI/CD processes in place

Some established ways of working that can be improved over time

The above tasks more often than not can be completed in around 1-2 weeks depending on constraints, and are ideal candidates for “Sprint 0” activities. I’ve observed from experience that it is the declaration of this period as a Sprint which is the source of confusion and disagreement since these tasks do not deliver value to the customer.

My recommendation would be to run a mini Kanban style project to complete these tasks/tech stories, and you’ll most likely find it coincidentally takes around an average sprint length to complete. Whether it’s called “Sprint 0”, a “project before the project” or “project initiation period” doesn’t really matter. Sure, you may offend some agile purists, but who cares! Lengthy debates on topics such as the naming of a 2 week period that occurs once in the lifetime of a project are an enormous waste of time and effort.

Keep in mind that the following are examples of items which should be avoided in this initial period:

Finding the core team members

Fleshing out low level details for stories

Estimating and completing features

[hashtagagile-blog]

The lifecycle of an agile development is open to perception and interpretation, depending on what you have heard, learnt or read about the methodology. Many will carry it out differently, a by-product of it's youth and rapid growth in the professional world.

There is a common theme I have seen myself, being lead UX on several government projects I have gained experience from the very beginning stages all the way to release of the eventual MVP.

'Sprint Zero', a phase that for some is called 'Inception' or just 'Scoping'. This is the initiation period where the department leads and product owner from the client side come in to talk over and solutionise on the project deliverables. What the definition of 'Done' is, what MVP is visualised as, the time frame and which activities we can justify (...user testing, interactive prototyping etc.).

Sprint one onwards is the heart of the agile development, the iterative stages of build, test and implement. In each stage of course there are stand-ups, retrospectives, testing and research. The driving force here is ultimately the user stories which are picked up, played and catered for by individual members of the team which is where the factor of progress is realised.

On from this, once development is completed you are going to expect a deliverable, at the very least MVP (Minimum viable product) which effectively is the bare bones of what the client initially asked for, working, tested and deployable.

This visual sums up those main phases which structure the agile development, it effectively comes down to interpretation and requirements for each project.

[uxpeepsmusings-blog]

So your organization has decided to implement Scrum, but you’re stuck, wondering what to do first. That’s understandable: For all of Scrum’s detailed processes, what’s the process for starting the process? Put another way, how does a team prepare for its first sprint?

[swagile]

Sprint Zero

There is much talk about sprints and the day-to-day running of a project.  Not enough talk, in my opinion, about the start-up phase of an Agile project. I like to use the Sprint 0 concept.  Its during this sprint, which can be any length depending on the scope of the project, where we capture enough information to put us in a position to be confident about starting proper, i.e. a deep enough, estimated,  backlog to start Sprint 1. We collect user stories, we think horizontally (architectural ideas), identify risks, do some UX concepting.  We might augment key user stories with more detail e.g. append use case documents to them if we think it's appropriate. The pressure to provide a realistic cost estimate plays a key role in determining how far we take Sprint 0.  It's a balance between doing enough to give you the confidence to make an estimate, against falling into the trap of analysis paralysis. Sprint 0 is not always required.  For example, if we have implemented something similar in the past then we are already in a position to start Sprint 1 i.e. deliver value to the customer, because we are already confident about our approach and development environment. Sprint 0 is about getting the team ready to start.  By team I mean everyone, even the Finance Director! By the end of Sprint 0 you should have:- • The Project/Product Vision • Some UX Concepts • The Backlog • The Architecture Overview • A Budget Estimate • Target Velocity and Burndown Chart ready • The Definition of Done • Stakeholder List • A Team or Teams Organised