The goal of sprint planning

Early on in this set of blog posts about Agile planning I talked about the common image of the planning onion, in which there are different layers of planning that start with the widest strategic view and progress all the way to daily planning.  So far I have written about strategy and portfolio planning in the earliest blogs in this series, then progressed to talk about product and release planning when sharing thoughts on product roadmaps.  Now I’d like to focus still further in and discuss planning for a specific sprint or iteration.  In my current context we work with two-week sprints and so my thoughts relate to team planning for a given two-week period of time.

This is really a huge topic; I could create several posts about it and people have written whole books on sprint planning.  Maybe I will write more extensively about this topic in the future, but for now I want to share thoughts on two big areas (broken into two posts):

  1. What is the goal of sprint planning?
  2. What is a good way to do this planning?

Weaving through both posts will be the idea that the key to effective planning is understanding priority and effort – relatively how important and how difficult are the various tasks.  This allows the development team to pull as many of the most important items as possible into a given sprint while also giving them flexibility if they find capacity changes.  With all of this in mind, let’s begin by talking about the goal of sprint planning.

To understand the goal of sprint planning, it is useful first to think about the reasons for developing software using an Agile methodology in the first place.  In this context several of the principles behind the Agile manifesto standout to me, including these:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Working software is the primary measure of progress (for a complete list of the Agile principles see this link:

The goal of Agile development with sprints is regularly delivering the most important increments of working software to the customer.

With this in mind, we can talk about sprint planning as having twin goals, one from the development team’s perspective and one from the viewpoint of the business.  For the coders, testers, designers, and architects working on developing the product, the goal of sprint planning is to make clear what they should work on next and roughly how much effort it will require.  For the business, the goal is to know what increment of working software they can expect at the end of the two-week sprint.  Pursuing these twin goals lets the development team know what to work on for the sprint and the business know what to anticipate from the sprint.

Taken together the goal of Agile sprint planning is for the development team to know what pieces of working functionality – prioritized by the business – they can commit to delivering with relative certainty at the end of the two-week sprint.  Regularly making and fulfilling sprint goals deepens the trust between the business and development teams as both come to understand the capacity or velocity of the team to produce on a consistent basis.  Certainly there are times when unanticipated problems arise that complicate development and compromise the team’s ability to deliver on the sprint goals – just as there are times when obstacles prove easier to overcome than expected and the team has added capacity at the end of the sprint.  However, making clear and realistic commitments through the regular process of sprint planning strengthens the relationships among the development and business team members as they together identify the most important things to focus on each sprint.  Disciplined planning promotes this focus as all the relevant stakeholders know what to expect each sprint.

In my current context I have seen greater benefits flow from sprint planning as we have invested more time in doing it well.  I’ll talk in my next post more about what ‘doing it well’ looks like for us, but for now I can confidently state that having the team take time to think through and plan its commitments for a given sprint makes the entire development process more satisfying both for the development team and for the business.  It doesn’t mean we never have problems meeting sprint goals or that we never have to abandon those goals mid-sprint when something unexpected occurs (you know that if you’ve been reading this blog for any length of time); but planning what we want to accomplish in a given two-week period and then tracking our progress against those goals energizes our team and deepens the trust that the business and sales folks have in our work.  Getting to this point hasn’t been easy of course because in truth it’s not that simple.

2-part sprint planning blogs coming soon

I’ve been on vacation recently and there have been things going on at work that have kept me very busy.  But I am nearly finished writing a two-part blog post on sprint planning that I want to get out soon.  Look for part one in a day or two once it is polished and then part two likely next week.  Thanks for your patience loyal readers.

So who decides when someone has to?

In my previous (long) post I talked about navigating potential conflicts that can emerge in Agile planning when a company has an inter-related set of products.  I suggested that product owners have a valuable role to play in navigating these collisions by facilitating communication, articulating trade-offs, recognizing leverage opportunities, and offering a wider perspective.  I also made clear that responsibility for each of these four areas must be embraced by all members of the development teams including designers, architects, coders, testers, and product managers.  I further made the (bold? naive?) statement that in an Agile environment that values open communication and collaboration across self-organizing and empowered teams everyone involved strives to navigate the inevitable collisions that occur across team plans without appealing to position, power, or expertise as trump cards to force compliance.  This all sounds nice in theory, but how do such ideals stack up against the real world of product development?

Here I must admit that my answer to this is partly shaped by my good fortune in being part of an organization that values striving for ideals.  Founded on principles and consciously pursuing multiple bottom lines, the company in which I currently serve as a product owner challenges every employee to be the best versions of ourselves and to seek the best ways to face and resolve conflicts within and across teams.  In a company where we seek to recruit, hire, and retain people based on character and values as well as skill sets we can both expect a higher level of adherence to the ideals I upheld in my last post and legitimately hold people accountable for doing so.  We certainly aren’t perfect, but we may have a higher than average willingness to seek ideal solutions in our honest pursuit of our goal to make a difference and not just a profit.

Of course, in truth it’s not simple.  We don’t always act or think in accordance with our stated ideals, and even when we do we still have different perspectives and sometimes conflicting agendas.  As each product team also has to be conscious of its own bottom line and not simply what might seem best for the company as a whole, there can be an understandable element of game theory that emerges around product decisions.  If one team builds a new feature first then that team will likely bear the higher cost (both financially and in terms of development time) and so it might be ‘cheaper’ to leverage someone else’s development than to collaborate and share the costs together.  If cross-team projects can be broken into their own separate development ‘threads’ with separate resources then the normal product teams can get more done by keeping ‘their’ developers working on ‘their’ priorities while a separate team of developers can be assigned to some cross-team projects.  And since every team worries about controlling its expenses all teams can fall into arguments about the proper ways to allocate the costs associated with projects that benefit multiple teams or the company as a whole based on how much they ‘wanted’ these projects or when they would have prioritized them on their own.  In spite of our shared base of common ideals we have yet to find an easy way to sort through these complexities and continue to search for the best approach to resolving the conflicts that arise from them.

While it doesn’t solve all of these difficulties, perhaps a metaphor might shed some light on one good way to frame the issues.  As usual, I will probably stretch this metaphor close to its breaking point so please bear with me.

In an orchestra each member and each section seeks to do its best both to play its own parts and to harmonize with the whole.  In an orchestra each person seeks to be the best she can be in full collaboration with other members and in overall pursuit of the music itself.  Each recognizes the valuable contributions that others can make and knows that the most beautiful music comes not from dominating others but from playing well together.  While at some times and in some pieces certain parts of the orchestra might gain more prominence, all together know that their unifying goal is to thrill the overall client base and keep them coming back (and paying) for more.

Agile principles and corporate strategy set the music we strive toward as we look to build the best products we can in the best ways to fulfill our purposes and achieve our multiple bottom lines.  Product owners, product managers, coders, testers, designers, architects, DBAs – all strive both to be the best they can at their roles and to collaborate effectively.  Working in concert with each other and our principles puts our potential conflicts into a broader context and motivates us collectively to pursue the best experience for our clients consistent with serving them sustainably and profitably.  Thinking along these lines certainly won’t eliminate conflicts, but it creates the right mindset for navigating them when they arise.

The context for working things out when well-meaning people pursuing the same overarching goals have different perspectives on the best way forward involves some forum for mutual conversation and decision making (think of this forum as the conductor of the orchestra if that doesn’t stretch the metaphor too far).  Some team of people meeting regularly to assess overall product strategy and help assess if each team is making wise choices can keep the entire product organization abreast of best practices.  A cohort of product managers and product owners must surely be a key part of that decision making team when clarity about the best path forward does not emerge organically from the teams themselves.  However such a group would likely also benefit from the valuable contributions of design, development, and architecture leads as well whose technical knowledge and development wisdom could offer helpful perspective in crafting product portfolio priorities.  Ideally – and in my experience this ideal is realized more often than you might expect – decisions about product direction rarely need the intervention of such a group; instead their regular discussions serve to foster a broadly collaborative environment in which solutions to potential conflicts emerge from those most directly involved and impacted.  But knowing that such a team can be appealed to when necessary provides helpful boundaries for resolving conflicts because in truth it’s not that simple.

When worlds collide

Groucho Marx once famously observed that outside of a dog a book is a man’s best friend while inside of a dog it’s too dark to read.  We could use a similar analogy to talk about Agile planning and say that good planning does not happen in a vacuum because either it’s too dark, cramped, and dusty to plan in there if you’re thinking of this vacuum or else it’s incredibly hard to breathe if you’re thinking of this vacuum  And neither is a good place for planning.

Effective and realistic Agile planning does not happen in a vacuum isolated from any other influences beyond the development team itself.  This is true not just externally – where good planning leans heavily on market intelligence and strategic insight about product direction – but also internally.  Plans for the development of one product may intersect with plans for another product built on the same underlying architecture.  Plans in the mind of the product manager may conflict with ideas that the design team envisions for the coming months, and these plans may in turn conflict with areas that the development team feels need attention.  As I continue writing about Agile planning, it is important to recognize the context in which this planning occurs.  Several of the past few posts have focused on the external context as I’ve discussed the need for solid market intelligence and holistic strategic goals.  Here I want to share some thoughts about the internal context for Agile planning, and to talk specifically about what happens when different plans collide.

First let me share briefly about the organizational context in which I serve as a product owner.  We are developing several different products targeted at specific market segments with overlapping but slightly different needs.  We also have a large group of internal users of our products who rely on them to empower the advisory and consulting work we offer.  These web-based products rest upon the same database and architecture and are increasingly accessed via a web face that is coalescing around common design themes.  Some of our clients use only one of our products while others integrate several in their workflow, making a unified user experience across these products important.  And all of this software development has accelerated in the past couple of years as we aggressively expand into new market opportunities even as we collectively figure out the best ways to apply Agile methodologies to our development efforts.

While in general we work well together across our different development and consulting teams, there are definitely times when our plans collide rather than coincide.  Two teams may have different perspectives on the best way to redesign parts of our website (while the designers themselves may have yet a third view in mind).  Two product teams may have conflicting views on when certain functionality should be prioritized for development or on the shape of new features that will be used across our client base even if they are first developed by a single team.  Product managers may want to enhance existing features or add new ones while development leads and testers may stress the importance of refactoring existing code to eliminate costly technical debt to make automated test coverage more comprehensive.

In theory these conflicts could be resolved by appeals to power or expertise: the ‘most senior’ person could insist on getting her way or the ‘expert’ in a certain area could mandate that everyone follow her opinions.  But in an Agile environment that values open communication and collaboration across self-organizing and empowered teams we strive to find a better way to navigate the inevitable collisions that occur across our team plans (more on this in my next blog post).  And in this navigation product owners can play a vital role.

I have written before about the image of a product owner as the bridge connecting different people involved in the development process (you can check out some of my earliest thoughts on this here if you’d like:  Hopefully without egregiously overtaxing this metaphor, the product owner serves as a multi-pronged bridge spanning the gaps potentially separating coders, testers, designers, product managers, and even distinct product teams so that all of the relevant stakeholders can engage in the set of conversations required to avoid or work through these collisions.  (And if the idea of a multi-pronged bridge goes too far, maybe view this as a web of interconnections with the product owner as the web-slinger – and who wouldn’t want to do that:  In a context with several inter-related products the team of product owners collectively plays a strategically important role ensuring that the relevant factors are given appropriate weighting in deciding how to navigate potential conflicts both within and across teams.  Strong product owners do this in at least four key ways which I will comment on briefly below recognizing that each one could be a separate blog entry on its own.

  1. Facilitating communication. A focus on communication is of course crucial in the light documentation environment of Agile development, but it becomes especially crucial when potential collisions arise.  Regular formal and informal settings for communication among the product owner team members allow them to spot potential conflicts as they emerge and sometimes avoid them through fostering the right discussions ahead of time.  Once actual conflicts within or across teams surface regarding priorities or development direction product owners can facilitate conversations involving the relevant people who can work out a solution soon after the issue becomes apparent.
  2. Articulating trade-offs. In their roles working with the team to move product development forward, product owners are often in a position both to recognize and to explain the potential trade-offs involved in pursuing one path over another.  The ability to help all parties involved in potential conflicts to grasp these trade-offs can allow the team to decide more objectively how to proceed when two ideas or teams are headed on a collision course.
  3. Recognizing opportunities for leverage or cross-product benefits. Because they see across products in the portfolio and because they have perspective on the product roadmap I talked about in my last blog post, product owners can also be uniquely well positioned to recognize opportunities for one team to leverage the efforts of another to enhance both product lines.  Teams might rearrange items on their backlog to tackle larger problems together or determine that both teams need to redesign one aspect of the product workflow to benefit both teams in their ultimate goals.  Regular conversations across the product owner team help to bring such opportunities to light, allowing the development teams to capitalize on opportunities to leverage both new development and refactoring efforts for greater mutual benefit.  This type of collective ‘backlog mining’ can of course benefit from the insights of folks beyond the product owner team as well, as the wider set of people focused on product development corporately find the best path forward for the entire product portfolio.
  4. Taking a dispassionate perspective that helps the entire team weigh the relative merits of competing plans. In addition to facilitating communication, articulating trade-offs, and recognizing leverage opportunities, strong product owners can also help the teams navigate potential collisions by offering a wider perspective.  Product managers focus on understanding and solving the persistent market problems of their target market, while developers and designers concentrate on the specific strengths of their respective disciplines.  Good product owners, with their emphasis on building the best products in the best ways, are able to bring a larger focus on the process itself.  The best Agile product owners are passionate about the way the team collaborates to develop the best product or set of products, allowing product owners to help the set of stakeholders weigh the relative merits of conflicting plans and determine the optimal path forward.

Strong product owners can offer a unique viewpoint when worlds collide.  Having (hopefully) strong relationships with one another and across the product management, architecture, design, and development teams, good product owners can help the organization navigate these potential collisions and reach strategically beneficial conclusions that strengthen the company’s entire product portfolio.  Of course, product owners are by no means the only members of a strong Agile team who can help with this navigation (that would be too simple).  In the interdependent web of architects, coders, testers, designers, product managers, and product owners, all members need to prioritize communication and a willingness to make trade-offs that benefit the entire company.  Even as product owners look across projects to recognize opportunities for leverage they must also expect to learn about these opportunities from other team members who can see potentials for conflict or convergence related to design, database, architecture, and codebase areas that product owners might not be aware of (which is a great reason to encourage regular team meetings of designers, architects, testers and others just as there ought to be regular team meetings of product owners).  While there are particular ways that product owners can facilitate this cross-team collaboration, they are by no means the only ones seeking to successfully navigate through potential conflicts.

Finding or making a way through possible collisions is a vital role in Agile product planning for growing organizations with an inter-related set of products.  The ability to serve as a bridge or facilitate a web among the many relevant stakeholders can make a crucial difference in the successful evolution of a product and the growth of the entire team involved in this development.  Fostering the kind of communication and collaboration necessary for the various self-organizing development teams to all move the product portfolio forward coherently is a challenge for product owners, but success in this endeavour is vital for both good Agile planning and strong product development.  Nurturing this strong web of relationships of course won’t allow the team to avoid conflicts altogether because in truth it’s not that simple.

Summary on my next two posts

It has been a little while since I’ve been in a good rhythm with my blogging but I am trying to get to one now.  I want to work through the remaining posts in the current arc about Agile planning.  Believe it or not I work hard to keep my blog posts concise.  I think a lot about product development and have many ideas I am eager to share, but I try to keep each individual post relatively short and focused.

My next post has grown beyond that.  As I tried to summarize my thoughts on how to handle some of the conflicts that can emerge around Agile planning I found I had too much to say to write a brief post.  I looked for ways to break it into smaller chunks but could not come up with a coherent way to separate the ideas I wanted to express.  So unfortunately my next entry is going to be a bit long, and there are a couple of lingering issues that I will put into a separate post beyond that one.

For those tempted to dismiss the next entry with a TL; DR (that is, too long; didn’t read) I give you the highlights here.  Hopefully this whets your appetite for digesting the full post later.  Thanks.

When conflicts emerge in the planning for the development of inter-related products there are four keys to navigating these conflicts successfully:

  1. Facilitating communication
  2. Articulating trade-offs
  3. Recognizing opportunities for leverage or cross-product benefits
  4. Taking a dispassionate perspective that helps the entire team weigh the relative merits of competing plans

Good product owners can help with these, but of course, in truth it’s not that simple.


The second book I want to share brief thoughts on here (the one I referenced in my earlier post on Wolfe’s A Man in Full) is a modern translation of The Emperor’s Handbook by Marcus Aurelius.  Translated by David V. Hicks and his brother C. Scot Hicks, this modernized version of the meditations of a Roman emperor and general is something I’ve been tweeting about for months as I slowly read through it.  If you follow me on Twitter (@asbiv) or if you read my blog post about this book back in January ( you know that I have found Marcus Aurelius’ thoughts on life, suffering, character, and purpose interesting even when I disagreed with him.  I have also really enjoyed the pithy and modernized language that the Hicks brothers use in their translation; it makes this book of Stoic philosophy easily approachable for contemporary readers.  And as I mentioned in the other book review I recently wrote, I was delighted to see how intertwined some of the themes in The Emperor’s Handbook were with those of Thomas Wolfe’s novel A Man in Full – though perhaps I would not have been surprised if I had remembered that both books were on the same list of recommended books found here ( and that I blogged about here (

There are of course some keys areas on which I differ from Aurelius in looking at life.  I don’t believe in Zeus or the other gods he references (although the fact that he uses Zeus, God, the gods, and Providence almost interchangeably may suggest that Aurelius also didn’t take these deities too literally).  I think pain, disappointment, heart-ache, and suffering are real and not simply a matter of an inaccurate perspective on the world and our experience of it that we can change at will.  Beyond this I fundamentally disagree with the inherent dualism in Marcus Aurelius’ worldview – the notion that the mind is true and eternal while the flesh and all physical existence is fleeting, unsubstantial, unimportant, and ultimately something to be denied and risen above.  My own view is that life must be understood as it is experienced: as holistic and corporeal beings whose bodies are just as much a part of us as our hearts and minds.  We cannot ‘rise above’ our bodies and the physical aspects of life because we are our bodies and we live as physical and spiritual persons in a world with real substance.

In spite of this significant philosophical disagreement with Aurelius and the wider Stoic perspective, I still found this book encouraging, interesting, and thought-provoking.  As I read this book I regularly tweeted quotes from it, mostly about the simple joys of being alive, our ability to choose virtue and wisdom even in the face of hardship, and the importance of keeping our own brief lives and pains in wider perspective.  I like the idea that no matter what we go through in life we have a fundamental ability to choose how we respond and that with those choices we can display our true character even when confronted by oppression or suffering.  I appreciated Aurelius’ repeated declarations that life is short and we are far less important than we tend to think of ourselves; this attitude reminds me to be humble and to take myself and my concerns less seriously.  And I resonated with his assertion that we should never allow other people and our desire to please them to control our lives or diminish our goals.  Plus I found many of his ancient observations both relevant and humorous in our post-modern context.

So while I cannot embrace everything from The Emperor’s Handbook I did truly enjoy the meditations on life, leadership, and character that Marcus Aurelius offered in his writing.  He didn’t make me a Stoic, but he did remind me to take myself and my problems less seriously, to remain true to my character in the face of both suffering and flattery, and to strive for a virtuous life no matter what obstacles I encounter.  Like most books I read (or movies I watch) I found elements I liked as well as those I disagreed with, but that should come as no surprise because in truth it’s not that simple.

A Man in Full

I mentioned in a recent update that I wanted to add another page to my blog where I can put in brief reviews of some books that I’ve been reading.  Two books I’ll be writing about soon that relate closely to the work I do are Grow by Jim Stengel (about how ideals power growth and profit for thriving companies) and Winning the Story Wars by Jonah Sachs (about the power of compelling stories in corporate marketing).  But before I get to those I want to write about two other books that tie well together; one is a modern novel by an author with several books that have been adapted into movies and the other is an ancient book from a Roman emperor and philosopher.  I had no idea these two books connected so well when I started reading them both earlier this year; but now that I have finished both I wanted to share some thoughts about them.  I’ll write below about the novel and in my next post talk about the philosophical work.

The novel is called A Man in Full and was written by Thomas Wolfe, author of Bonfire of the Vanities and The Right Stuff among numerous other novels.  It focuses on an inter-connected set of men in Atlanta near the end of the 20th century and involves issues of race, class, sex, power, and purpose.  Like other of Wolfe’s novels (in my opinion) this one takes a little while to get going as we are introduced to the wide cast of characters, four of whom emerge as the main actors in this vast plot.  Once the story gets moving in earnest the reader is pulled along a wild ride of success, failure, intrigue, and satire that makes this a humorous as well as an insightful read.

What ties this novel to the second book I will write about is the central place that Stoic philosophy occupies for one of the main characters who first encounters a book on the Stoics while in prison.  This man (Conrad) becomes something of a ‘Stoic evangelist’ seeking both to live out the ideal of wisdom in the face of tragedy and to encourage others to take the same approach to life.  The potential influence of Stoic philosophy on modern life added an intriguing element to this novel for me because I was currently reading the writings of one of the last great Stoic philosophers Marcus Aurelius.

Unfortunately (again in my opinion) it was at the climax of A Man in Full and Wolfe’s portrayal of how Stoicism might impact the central dilemmas of the novel’s protagonists that this otherwise strong book fell apart.  I felt the same way years ago when I finished Wolfe’s earlier Bonfire of the Vanities; the conclusion of a strong book about race, money, and power in modern America ended with the main characters making choices that seemed not to fit with their portrayal throughout the book.  Instead each of these books ended abruptly and in an unconvincing manner, giving the impression that Wolfe was not quite sure what to do with the grand ideas introduced in the novel.

Although (spoiler alert if that matters to you) Charlie Croker’s apparent embrace of a modernized version of Stoicism at the novel’s conclusion mars an otherwise gripping book, I still enjoyed reading A Man in Full; I also look forward to sharing some of my own reflections on the contemporary relevance of Stoic philosophy when I post my next book review shortly.  And I encourage you to read Wolfe’s novel for yourself and form your own opinion because in truth it’s not that simple.