Tag archive

sprint planning

An Agile Team Task by Any Other Name – A To Do

in Agile/Agile Engineering/Leadership/Teams by
Sprint Planning Hell

Let me first say, I know the idea of task decomposition is fairly well covered and some might call it a basic practice of any team; however, as a coach helping teams to adopt agile software development, I don’t always see teams finding this practice of defining “how to get to done” as a natural team planning activity. Instead, I see teams getting frustrated with a clunky approach or a high-level of disengaged team members or a member of the process police controlling the meeting that is distinctly a team meeting or I still see the “lead” define the tasks and simply dole them out.

Defining “How” to get stuff done as a team should be the straightforward activity around software development. It should be an engaging activity of brainstorming, learning, sometimes arguing, and ultimately a good feeling of “let’s git’r done.” All-too-often it seems like a torture technique riddled with challenges. These challenges are often rooted simply in poor practices, some of the which include:

  • Creating faux work breakdown structures (yes, I said it — WBS) of standard tasks (e.g. each story has “Design”, “Code”, “Review”, “Test”, “Deploy” tasks). Some would argue this is not a poor practice, but tasks should have context and be relative. Not to mention, this is kinda mundane, requires no thought, and is flat out lazy and contrived.
  • Focusing on the accuracy of hour level estimation. If we are consistent with relative estimation and looking at cycle time, we can come up with the “low risk” and lean approach to determine which stories to work on. Estimation at this level is more of a measure of certainty.
  • Creating tasks and tests that are ginormous — like a 40 hour task for a two week iteration. If someone tells me that it’s going to take 40 hours, then I view that as high risk and we need to keep talking about it to better understand it.
  • On the other hand, creating micro tasks — yes, so many that the Task board looks like like a sticky note factory exploded on the wall or invoke pagination within the tool.
  • Having the developer and tester creating tasks and tests in isolation without any conversation with each other or the rest of the team.
  • Oh yeah, let’s not forget when I get asked about reports that measure how underutilized people might be. Often the focus of understanding “How” becomes simply an exercise to maximize utilization.

That last point about utilization, it seems like a frequent driver of the planning exercise. It’s odd in that sometimes people think that if we don’t have a plan with everything defined that we are going to do before we go do it; well — when the stuff we do get done is complete, we’ll simply stop working and sit there and stare at each other. I’m pretty sure that this is never the case and if it is, either get new people or look in the mirror.

Does any of this sound familiar? Does any of this frustrate you?

Well, I have a few ideas for you to try — most of these are common sense and talked about by others, but it’s always good to mix it up and try something different to get out of the rut or remove the pain associated with planning.

First, abandon planning using ideal hours — I know, I’m crazy — but hear me out. The common rule for any to do or task is that it should take no more than a day to get completed, ideally less. Tobias Mayer’s book called The People’s Scrum contains a curated set of his past blog posts, one in particular called, “When is Scrum not Scrum?” explains his reasoning for non-estimated, day or less tasks — (1) eases tracking – just burndown tasks — the burndown is number of remaining open tasks and (2) it helps to unearth unforeseen impediments that are often just part of what we normally do. While these are great, I would add that focusing on estimates and accuracy of the estimates actually just results in taking the eye off quality and flow of value.

Next, decompose just enough stories to commit to the goal and get started. The Scrum Guide is pretty clear about this:

… enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting.

Now, new teams may need to decompose all stories during a sprint planning, but teams that have been together for a while may be able to quickly determine what stories to do in the next two weeks, how they fit a incremental goal, and then just go. Don’t make your sprint planning meetings more painful — if you are planning for 2 hours and you have enough work to start the sprint, then go start.

Try different techniques for this meeting that encourage engagement. For example:

Taskstorming. A simple approach where the team selects which stories they are going to work on based on past velocity and then, interviews the Product Owner on each. During the interview, the teams is noting on sticky notes the tests and tasks. Once a goal emerges, then it’s time to task [and test] storm. On a whiteboard, write the title and draw a large box for each story. Now have the team place their stickies up on each story. Duplicates can be discussed as well as someone can put up something that doesn’t make sense to anyone else — well discuss it. Through this process, let the conversations flow – observe a story with a ton of task, then maybe it should be broken apart? Taskstorming not only makes the meeting more efficient, but it’ll make it more effective because everyone is involved and engaged in the process. At the end, have folks pair up and help get the data captured in your favorite tool (which means VersionOne).

Other techniques you can try include Task-n-Tell and Test First Tasking.

Finally, as I’ve mentioned in a couple past blogs, put this on the team – this is a team activity. If you are a team member, take ownership of this meeting and you lead it. The Scrum Master or Lead or Facilitator of the team would typically do this, but if you find them directing or assigning tasks out without engagement. Well you have a problem and the best way to change it is for a team member to take over. If you are a Scrum Master or Lead and you are struggling with getting the team engaged, try something new — don’t be insane. Try introducing a facilitation game or asking someone else to facilitate (not the product owner or anyone else in a position of authority).

No one should suffer through a sprint planning meeting. Yes they can be hard, but they shouldn’t be torture — so, inspect and adapt. Time to make them fun and effective.

Remember that at the end of the day, tasking is simply defining the proverbial To Do list to get a story done.

Come to the Science Fair

in Product Management/Teams by

Remember that thing we folks that practice Agile call the Agile Manifesto.  You know the thing that where 17 smart folks got together and came up with a set of four values and twelve principles to help guide and shape the behaviors of those involved in software development.  Everyone might not be able to rattle off the principles, but most of us understand and appreciate the common sense of the four values.  At the core of all the Agile Manifesto values is a well maintained relationship between the delivery team and the customer (or Product Owner).  And this is where challenges have emerged and often things start falling down.  Here’s a common scenario that often plays out:

An organization starts making a shift to use an agile related process, let’s say Scrum.  They train the delivery team and the product owner, then kick it off with a team or two.  Everyone starts to work and they start seeing productivity gains right away.  And the teams are seeing vast improvements in communications and building products that customers like.  The organization then says — let’s have a few more teams start drinking from the Agile fountain.  Things are going well, but what starts happening is that during this scaling process — people start competing for meeting rooms during the sprint planning and review cycles, and the product owner’s time quickly becomes a constraint. Thus, teams start alternating their sprint schedules to deal with the room/resource issue and the product owner spends less time with all teams and seems to only focus on those teams that work on things that are not doing well or they like.

Now you are asking, what’s the problem?  Well, one of the best things that you’ll find when you start working in small incremental delivery cycles is that the teams form a rhythm (or cadence).  This helps for predictability that helps the organization in planning and more importantly, helps the team members in planning their lives.  Most people like repetitiveness and everyone is habitual (or at least most folks involved in software development), so by having multiple teams on different rhythms — organizations lose the natural state of “steadiness” that comes with shared cadence.

The other big problem with the scenario above is that the face time and feedback with the customer (or product owner) is critical to having success with all four of the agile values.  When teams start realizing that time with the product owner is being a challenge, they tend to simply give the product owner a pass on attending any of the iteration planning and or review — and they just ask for his or her time for stories and acceptance criteria.  This means that they lose out on the critical feedback that comes out during the reviews and demos.

Does this sound similar?  If so, here are some ways to help overcome these common time constraints that appear when you start scaling out agile.

  • Introduce a Gap.  If you are using an iterative approach, introduce a gap between your iterations.  The idea is to get everyone on the same iteration schedule and rhythm and by adding the gap, you’ll give time for folks to juggle room schedules and stakeholder time to ensure participation.  During the gap, the team will have time to properly plan the  upcoming iteration, work on a design/research spike, and or work on an item from the team’s technical wish list backlog.  The gap also can afford the team a quick breath and might also be an easy period to squeeze in some personal business time.
  • Go Short.  This may seem to be non-sense; however, if you are using an iterative process then trying working in shorter cycles.  Although it takes some adjustment, shorter cycles reduce the time it takes to iteration plan and review.  The end result is a tighter focus and that focus is generally on what is needed next.  Similarly, move to a lean or continuous flow process (give this a read to learn more).
  • Lunch-and-Collaborate.  Schedule meetings around lunch and, of course, have food.  Lunch is generally less formal and can be perfect for brainstorming, story workshops, demos, and team building.  Although team members some times need a break from work, most team members don’t mind meeting when food is involved 🙂
  • Record Your Demos.  A meeting that you don’t want to miss out on getting feedback is the demo; however, this is a meeting that for some reason the product owner and other key stakeholders will often miss.  This meeting is not only about showing off and having the team get some positive feedback — it is more about just getting feedback.  Try recording the demo.  Make the video less than 10 minutes, don’t worry about it being Oscar quality, just get it done and sent out to all those that can give input.  Solicit feedback within 24-hours of sending out the video, re-enforce the need for the feedback and participation.   In addition to the value of getting feedback from the stakeholders, the recorded demos are great timeline artifacts that can be used for retrospectives.
  • sciencefairConduct a Science Fair.  Often when scaling agile, there will be a product owner that works with multiple teams and making time for reviews and demos for all teams around the same time is near impossible.  So to get around this, conduct a science fair — have teams assemble in a meeting room and demonstrate their latest accomplishments.  This is not only a fair for the product owner, but this is a great time for teams to get together and see what the other teams are up to.  This is an event that the whole organization can be a part of and it is a great way to get an organization excited about capabilities forth coming.

So if your teams have had some challenges with face-time with the customer, difficulty establishing a cadence, or you are just not getting valuable feedback — try one or all of the approaches above.  These approaches can not only improve the collaboration, but they can be fun and challenging which will show up in improved team morale.

Go to Top