Time-boxes, goals and realizing outcomes

Goal is defined as:

the end toward which effort is directed” or “the object of a person’s ambition or effort; an aim or desired result.

I don’t understand the debate over the Sprint Goal.

I also don’t understand how a teams can function and focus without goals (be they implicit or explicit although I would suggest that there is a danger in not making goals explicit).

If a team carves out a fixed set of time (a time-box) to do some work, they already have, albeit implicitly, established a goal i.e. completing a certain amount of work in a certain amount of time.  I don’t consider this type of a goal to be a best goal we could come up with because it’s output focused and you know I favor outcomes over outputs.  I will concede however, that this type of goal is probably better than no goal at all.

From the Scrum Guide, the Sprint Goal is:

an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Seems pretty straightforward to me with a lot of latitude for the Scrum team to create their goal.  What do you think?

If your time-boxed work period has no goals, no aims, no objectives, no desired end what exactly is your team doing?  Where are you headed?

(I’m pretty sure some folks reading this are thinking to themselves that time-boxing is an archaic practice and should be dropped altogether.  Stay tuned for my next post).

And while this post has focused up till this point on teams working with time-boxes, I will go even further to suggest that any team that is developing and delivering software in support of a broader organizational vision – yes I’m looking at all the teams that say they are using Kanban out there –  that doesn’t have time-bound (see Agile Manifesto Principle #3)  goals is operating irresponsibly.

Goal are very useful.  Use them wisely.  Use them well.


Projects Are Temporary…

I recently tweeted the following: 

Projects are meant to be temporary/transient endeavors for creating ‘new’ things. Both the PMI and PRINCE2 definitions of project management makes this very clear.  A review of project definitions show that projects are temporary because they have a defined beginning and a defined end.  The end is defined before we even start the project.  Aspects of the project such as the funding, the team(s) and other resources needed by the project are also intended to be temporary as the endeavor is transient.  Projects are also intended to be unique or as I like to put it, one-and-done type endeavors. When the project is done, it’s (supposed to be) done.

Examples of projects abound.  We don’t need to look very far to find them. Right now, the road that runs through my village in Eastern Nigeria is being tarred – it is a project.  It’s a temporary endeavor with a clearly defined end that was established at the onset of the endeavor.  Other examples include endeavors such as remodeling your kitchen, building a fence, moving servers from one datacenter to another datacenter or helping your 3rd grader come up with a collage of his Nigerian heritage.  You get the point; projects are temporary one-and-done type endeavors.


As the diagram above shows, not all endeavors are “temporary, one and done”.  The category that is of the most interest to us is that of endeavors that are long-lived with repeating activity as most of the software developed in organizations belongs to this category (regardless of whether the software is for external or internal use) as the software is evolved until it is no longer needed or used by anyone.

It’s imperative that organizations understand the nature of their endeavors so that they pick the most appropriate approach for handling them. Long-lived endeavors need an approach that is different from the “project” approach. Treating long-lived software development endeavors as if they are projects yields sub-optimal results.  These sub-optimal results will be the focus of my next post on this subject.