Detailed Sprint Planning Agenda

No Sprint Planning meeting will be the same, but I have observed some very practical steps to help you power through your sprint planning and ensure the essentials are covered.

Some assumptions:

  • Iterations are 2 weeks in length. (adjust time boxes listed below if you do 1 week or 3-4 week sprints)
  • Teams have some level of cross-functionality
  • Product Owner is embedded in the team and in attendance

Sprint Planning Agenda:

  1. (15-30 min) Recap of current sprint
    1. What is done?
    2. What is left and why?
  2. (5-10 min) Prioritize any leftover items – The PO decides if left over stories should move to top of sprint backlog or sent back to the backlog. (Do not assume that because something was a high priority before that it for sure is a top priority again!)
  3. (5 min) Close previous sprint in ALM tool (Jira, VersionOne, Rally, etc)
  4. (15-30 min) Revisit estimates for carryover stories. (Look for TOTAL effort, not just remaining effort. This is key for establishing velocity)
  5. (5-10 min) Evaluate capacity of the team (check for PTO, training, etc)
  6. (90-130 min) Create the Sprint Backlog – Pull stories from the backlog to create the sprint backlog one story/task at a time.
    1. Break each story/task down to sub-tasks
    2. Estimate hours for each sub-task (optional)
    3. Quickly Re-visit the estimates for the stories after tasks are created.  Still seem good? (Your estimate was first created in backlog grooming, now you’ve gotten more specific and need to make sure it still is accurate)
    4. Note: if the team is not yet highly cross-functional you will need to take a look and who these tasks might be assigned to. If you only have 1-2 people, a team with a specific skill set you do not want to create a situation where the rest of the team is blocked because they have too much work. If the team is cross-functional you do not need to assign anything to anyone other than the first task an individual will work on after sprint planning.
  7. (10 min) Fist of Five – Ask the team about their confidence level for the upcoming sprint items. Specifically, this is trying to gauge if they feel their commitments are realistic, and there is nothing blocking them out of the gates. If there are outliers take the time to discuss and adjust sprint forecast as appropriate. Remember, you can always pull additional items from the backlog should the team finish all items in the sprint backlog.
    1. 5 fingers: I am 100% sure we will complete everything this sprint.
    2. 4 fingers: I think it’s probable we will complete everything this sprint.
    3. 3 fingers: There’s a 50/50 chance we will complete everything this sprint.
    4. 2 fingers: I think it’s unlikely we will complete everything this sprint.
    5. 1 finger: I am 100% sure we won’t get everything done this sprint.
  8. (10 min) Create sprint theme/goals – This could be action items from Retro, or focus on collaboration, or some vision from the PO about a feature.

I want to use agile, but my organization doesn’t want to

tumblr_n4ef3ynCZP1st5lhmo1_1280

Fear not agile warrior, you are not alone and help is on the way.  They are many situations where someone just knows that agile could help or even change the face of the entire company if utilized…yet someone or many people within an organization are opposed to the idea.  So what should you do?  First off what are some reasons someone would be against agile?

  1. The’ve been on a team where agile was used, and failed.
  2. They don’t know enough about agile or have misconceptions.
  3. They don’t believe agile is right for their organization/product.
  4. They’ve worked with an Agile Coach/Scrum Master/Consultant that was not very good at their role.  Yes, not everyone does their job well…even in the wonderful agile community.
  5. They are from the past (I kid…I kid! That was an IT Crowd reference)

Now for the part you really came to this blog post for: What are ways I can help my organization adopt and/or support agile?

  1. Start emphasizing agile principles in whatever work you are doing. As a consultant that works on a wide array of projects with a variety of methodologies, I’m often tested with how to apply principles on a personal level. Getting out of the theoretical and nitty gritty practical application is a great exercise towards see if/how agile could work at your organization. If this is something you feel is “out of your league” or you just don’t have the time to do, it’s OK.  There’s other ways to makes strides towards becoming more agile.
  2. Propose solutions to problems from an agile perspective but without using agile lingo. Some people are just turned off to agile terms and immediately roll their eyes when you say “backlog grooming” or “daily scrum”. But if you are able to problem solve using agile principles you could begin to win over even the harshest of critics.
  3. Create a mini scrum board for tracking your own work. I heard a story of a person who was trying to advocate for their company to adopt agile, and started doing a scrum wall in a shared space.  Pretty soon scrum boards were up all over the company.  Some were labeled “Inspiration wall” or “Wall of vision”.  Everyone from IT to Sales was using them. Baby steps can be better than no steps, right?
  4. Contact consulting companies. See if they would be willing to share about agile within your organization.  Some consulting companies will do this for free because it’s a great way for them to help your cause, as well as demonstrate their expertise in this area should you need their services down the road. Or see if they are willing to just share free resources with you.
  5. Join user groups and contribute to the agile community. There have been times where my primary daily function was far from an agile focus, but I was able to stay energized by attending local groups or writing blog posts in my personal time.  Also, sometimes effective reflection comes when you are looking in from the outside.
  6. Find a new opportunity.  (Please take this with a grain of salt as it’s just my opinion.) This for many reasons isn’t the first option anyone would like, but it may be the right solution. As the industry seems to be moving more and more towards adopting agile, it’s less likely that a company is just flat out rejecting agile. It could be that they proclaim to use agile but it’s very broken or dysfunctional. These kinds of situations can cause stress if you are a firm believer in the agile principles. But is the disappointment or stress consistently outweighing the rewards or satisfaction experienced? If yes, it may be time to look for new opportunities.   Robbie Bach wrote a relevant article you may find useful called “Knowing When To Walk Away

What about you? What advice would you have for someone in this scenario?  I’d love to hear what other people have done or are doing.

How to measure success in an Agile organization

**Re-posted from https://www.slalom.com/thinking/how-to-measure-success-in-an-agile-organization where this article was originally published.

Any organization adopting Agile faces the challenge of figuring out how to measure success. “How will we report to executives?” and “How can we standardize reporting across multiple teams?” are some of the first—and most important—questions that pop up. Answering these questions without compromising the spirit of an Agile transformation is critical to adoption.

Why? Because every metric you put in place will generate some type of behavior, be it positive or negative. That’s why it’s imperative to exercise a vast amount of diligence when working to define your metrics.

In the world of Agile, success can look very different than it does in a traditional Waterfall, fixed-scope environment. One of the cornerstones of Agile is to work on what’s most important to the business and deliver value as soon as possible. Here’s an example: the team goes into a sprint or release and commits to completing five items. But after work begins, the team learns that the number-one priority will require much more work than expected due to new requirements or bugs discovered during development. Poor planning isn’t to blame; the team just has to make adjustments based on new information. Everyone agrees to focus on the number-one item to complete by the end of the sprint, leaving items 2-5 unfinished. They refocus, successfully complete item number one, and deliver it on time. But the team only delivers 20% of its expected scope at the end of the sprint.

To many Agile teams, this could be considered a complete success, because ultimately the percentage of original scope isn’t as critical as delivering on what’s most important. So in this scenario, the traditional measure of committed vs. completed can be a poor measuring stick.

Let’s look at what could happen if the success of this team was measured by what it completed. The team learns that good numbers are more important than delivering on the top priority. They then start padding their estimates to ensure that they have plenty of time to finish without any risk of backlash. Now you have valuable energy being wasted on navigating a process rather than getting things done. You’ve invited some of the more negative aspects of the Hawthorne Effect to come and run rampant on your project and team.

For an Agile organization to be successful, there has to be a general assumption that people are working hard and want to do their best. The role of a good leader is to enable teams to work smarter, not harder.

Here are seven traditional and not-so-traditional ways to measure the success of your Agile team.

1. Measure teams rather than individuals. A study conducted by Team Builders Plus found that “individual performance data are of less value (judging from the ratings and number of organizations tracking it) while team data reinforces collaboration and problem solving.” Collaboration is a key part of any Agile team that focuses efforts on the outcome of a project rather than a single person’s output.

2. Keep track of the percentage of the highest priority items being delivered. If your team’s focus is on delivering what is most important first, you can keep track of this trend over time. If the team is always delivering on priority two and three, but missing number one, you can use it as a coaching opportunity to help increase collaboration.

3. Measure the team’s satisfaction. You can be leading a team that is delivering at a high level, but if they’re miserable, you’re in a dangerous place. Part of a team’s success is the overall satisfaction of its members.

4. Evaluate your software. There isn’t a universal solution for determining if you have “working software.” Some of this relates back to customer satisfaction, but you could also measure if the work being done is truly solving problems—or if, in fact, it’s creating more.

5. Show the business value delivered. This may require more work up front, but if you have an idea of the value for a particular story or project, you can tell the story of the value that was delivered.

6. Provide a narrative, not just data. Why spend time collecting, packaging, and sharing data that really has no bearing on a team’s success? Sometimes even providing 3-4 sentences can give much more useful information than a pie chart. Visualization of data is definitely a good thing, but think carefully before defaulting to visualizations.

7. Measure anything the business says is important. Easier said than done, but as a guiding principal, focus on what the customer is saying is important. If they only care about 2-3 things, why give them 15?

Now you’ve got the metrics, but what do you do when ground forces at the executive level are resistant to Agile? First off, don’t react when people are critical or have a different perspective about what should be measured. You’ll be more successful showing people how Agile can enable the metrics they want.

Of course, there’s still a chance you won’t be able to reconcile the expanse between the pro-Agile and anti-Agile parties. In VersionOne’s annual Agile survey, 53% of people said an organization’s inability to change its culture was a barrier to adoption. There’s no silver bullet here. Another revealing statistic from that same survey was that 35% said trying to fit Agile into a non-Agile framework was a barrier to adoption. The research speaks for itself:you can’t always expect the metrics that work for a Waterfall project to apply to an Agile project.

The workplace is full of spreadsheets and databases, amassing ever-increasing amounts of information. With that, the definition of success—specifically in information technology-centric groups—has changed dramatically over the last 10 years. I’m a firm believer that success in its purest form can be measured by how happy your customer base is with the product or service you provide for them. That’s why the Agile Manifesto emphasizes “individuals and interactions over processes and tools.”

“That’s Not Agile”

right_way_and_wrong_way_sign-other_zps8c090af3

If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience.  Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things.  This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset.  The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to.  I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!”  No.  What I am primarily addressing is the way in which this topic is approached.

So, who’s right?  Maybe saying “that’s not agile” can be valid.  Or maybe we’ve lost sight about what agile is all about.  Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile.  And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  1. Don’t try to impress anyone with your agile credentials.  Do try to identify things that have been successful on similar teams/organizations.
  2. Don’t be preachy when trying to present new ideas.   Do suggest ideas with a humble and flexible attitude.
  3. Don’t rely solely on past experiences of what worked for other teams.  Do spend a lot of time listening to people’s needs an challenges.
  4. Don’t react when people are critical of agile.  Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  5. Don’t press your own agenda.  Do thoroughly understand how you can support management’s vision.
  6. Don’t treat the agile principles as a law.  Do use them as a guide for making continual improvement.
  7. Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  8. Don’t be too quick to judge what will work best for  a team.  Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

 

Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution.  What things are important to you as an agile proponent in these regards?  Do you have any good stories to share?