Agile: Sprint Planning Meeting

The “other” meeting in Agile/Scrum. The Sprint Planning. You already have your “daily standups” or scrums going, but you need to actually *plan* your sprints. Before you start doing agile, you need to have an initial sprint planning. Call this pre-agile process sprint Sprint Zero or Sprint 0, or whatever, but it is going to be different than the sprint plannings after it. Why? Well, first let’s look into the planning pieces.

Now, you can split parts of these up into different meetings, but I like to keep them all together.

1. Retrospective15-20 minutes where you go around the room and ask each person. What went good this sprint, what went bad? Places to improve, places to keep things as is, what did you learn, etc, etc.

2. Review/Demo – 1 hour to 2 hours of going through all the stories you have completed in the previous sprint, reviewing with the “business” or the rest of the team, or product owner, etc. People can ask questions, and just getting all eyes on things helps to maybe find something subtle that someone else might have missed, etc.

3. Planning – This is the meat and potatoes section of your Spring Planning Meeting. Here is where you score all your stories that you have to score for the next sprint, or stories that are unscored in the backlog. This section of the meeting could last 2, 3, 4-6 hours depending on how many stories you have

So why would Sprint Zero be different? Well because you are just starting agile, you don’t have a Retrospective or a Review, you just do planning. (A more in depth post on just the “Planning” section is forthcoming)

Once you have scored all your stories, you are ready to go. After you go through your sprint, and you are nearing the end, you want to have another Sprint Planning Meeting, to plan out the next sprint. You do this type of “sprint”-ly iteration.. well, forever, or as long as your project is going to last.

I have found that holding sprint planning meetings starting early in the morning are better than the afternoon, just because people are more alert.

Also, having a good remote viewing option, such as Goto Meeting is going to make any remote do’ers happy.

Having some food and snacks for the team always is good too. A larger room where it isn’t as cramped is going to be good. Stuffing everyone into a smaller room for 6+ hours could lead to some crabbines, as well as just sweatiness 🙂

Of course, the Scrum Master is going to facilitate the meeting, but you might have one person or multiple do’ers drive the review/demo.


Agile: Roles – Scrum Master

Funny title, of course. Everyone with no idea about Agile/Scrum always laughs when they hear the title. Scrum Master (or is it Scrummaster?) – What is that? What a goofy title?

Yeah, but it is what it is. You are probably trying to run some kind of Agile/Scrum process, and you need then a Scrum Master 🙂

But what does a Scrum Master do? Well a lot of it might depend on your process and team but here are a few things (there are probably a hundred more)..

  • Facilitate the Daily Standup/Scrum
    Each day when you meet for your 15 minute standup, the Scrum Master should make things start on time, and keep flowing, and make sure people are answering the 3 questions (What I do today? yesterday? What is in my way?). The Scrum Master should cut off people from going long, make sure things get tabled or moved to a hallway discussion instead of taking of everyones time.
  • Make sure the Burndown/Velocity is being tracked
    The charts! Of course, someone needs to make sure the metrics are being tracked and also displayed. Now depending on your team, it might just mean .. well, nothing but making sure do’ers are updating their burndown correctly. You might have virtual charts. But in some teams, you might need to print the charts for the board, or you might even need to add the burndown yourself depending on your process/system. Keeping track of these metrics is key. You want to keep people informed of your progress every day (at least for the burndown – I like to track velocity as a bullet chart for the sprint and update each day as well).
  • Get all the Stories Ready for Planning
    In some teams, the scrum master might be the only person doing this, in others there may be a group of analysts, etc. But the Scrum Master should be sure to have the stories ready for planning, to score and discuss. Your team probably has a backlog of bugs, features, enhancements, technical debt, and it should be prioritized, but the Scrum Master should be where the buck stops to make sure everything is in order for planning.
  • Facilitate Sprint Planning
    Just like facilitating the daily scrums, the Scrum Master should facilitate the “Sprintly” Sprint Planning meetings. Review, Retrospective, Scoring. Keeping things moving, being an observer but not really a decision maker – that is for the team to do.
  • Be the “Blocker” From Outside Distractions
    Once you start doing Agile, things change, sometimes they have to change dramatically. If your team of do’ers is 3rd level support, or even 1st level support, they are going to need a buffer or blocker from outside distractions. People wanting things now! and support calls and walk ups, and everything else you can think of. The Scrum Master should and needs to learn how to say “No” to everyone when needed. “No, we can’t do that now, but we can look at doing it next Sprint” or.. “No, we can’t look at this right away, but if we get ahead, we can pull it in.. maybe”, or “No, we (just flat out) aren’t doing this”
  • Work with Product Owner on Story Prioritization
    The Scrum Master needs to work with the Product Owner (another Role for another blog post) to get the stories in order, and prioritized. This should happen sometime a few days or week before the Sprint Planning so things can get organized without being rushed.
  • Drive the Process, Improve the Process
    As with everyone involved, the Scrum Master should try to improve the process along the way. There are always way to do things differently which might lead to things running smoother. Change the day of the planning? Print cards? Auto burndown? etc, etc. The Scrum Master should work with the team and Product Owner to help continuously improve the entire process, and the Scrum Master should be the driver of the current process. People have questions on the process? They should ask the Scrum Master.

As you can see, those are just a few of the things the Scrum Master needs to do to help the Agile/Scrum process along. Many times, teams don’t have someone that will take the bull by the horns and drive the process, step up to the role. Other times it is just apparent who the person should be, and in others, it is a well defined role.

The Scrum Master’s role is very important in the process, as much as the do’ers and the Product Owner and others..But they should be the ones that *own* the Agile process and help move things forward.


Agile: Retrospective

The retrospective. The cousin of the “postmortem”. Why not a postmortem? Because our project didn’t die. We want to reflect on what we did right, wrong, how we can improve, what did we learn.

What is the retrospective? I like to have a 15-20 minute section before “review” and “planning” in the Sprint Planning Meeting. Everyone goes around and says what can we do better? What did we do bad? What did I learn? Capture the thoughts and feelings of people and look back at the last retrospective and see what you did this sprint to improve on last sprint.

The hardest part of this “retro” seems to be 2 things, depending on team. Some teams find all the *bad* things and list them out. Some just find all the *good* things and list them out. You need to have a balance. Some things always go better, some worse, so put them out on the table.

If you don’t know where you came from, you don’t know where you are now, or where you are going.


Agile: Scoring

Once you have your stories defined and you are ready to “score” them, there are some things you need to keep in mind.

What scale are you going to use for scoring?

I use 1,2,3,5,8,11, and 13. Why? Well, that is just what we used when I started doing Agile, and it seems to work 🙂 Fibonacci + 11. I know I probably should change it so it kind of goes along with the more mainstream numbers that some 3rd party tools and other people recommend. Maybe, someday 🙂

1 is the lowest, 13 the highest.

At first, the team has no idea what a 1 or 2 or 8 or anything is. It takes time. Over time the team gets a gut feel for what a 1 is, or a 3, or whatever.

Don’t equate points to time! No, a 1 isn’t an hour, or a day, or X. It is a 1.

What are points?

Well, I try to explain it as time, effort, complexity, outside factorness, craziness, etc, etc. You kind of have to bundle all those things up and say, yea, that is a 2. It is more than a 1, less than a 3. Each team is going to have a different meaning for what a 3 is.

During your sprint planning, what you want to do is give everybody a pack of “planning poker” cards so they can score as you go through stories. (There are also web apps for virtual teams, iPhone apps instead of using planning poker cards). As you get done reading the story, and answering any questions, the team should “score” – show their cards. If they are all the same – great! You have a winner.

If some are different, then you discuss or come to an agreement on why some do’ers think it should be higher or lower, and get a score at the end. Example? 6 devs, 4 say it is a 2, 1 says a 3 and 1 says 1, well, most say it is 2, do the other 2 devs agree? if so, you can mark it a 2. If not, you might discuss why. The one dev saying it is a 3 might say, “what about this an that” and then everyone realizes, oh yeah, it is more than 2, and you go with a 3.

What happens if you see 13’s?

What I try to do is say – if you score it a 13, then the story is too big, you should break it up into smaller stories. With that logic, you should never have a 13 on your board.

The biggest thing to remember is that the team is going to have to take a few sprints to get used to the scoring, and understand how stories fit into points. You ARE going to over and under score – it is just reality. But don’t adjust the scores during the sprint. Things just tend to work themselves out over time. What you can do is capture actuals at your retrospective and compare to what the original scores were. The team might get a better idea on what they should be scoring things then. Another thing to try is a scoring guide. After some time, you can say “every story we do that involves making a new button on a form is usually a 2” so then if you have a story like that, and the team scores it a 8, or they don’t know what to score it, you can look back at your guide and say -hey, we usually score these 2’s, so is a 2 ok?

Who scores?

This is a good question, who should score? My opinion? Just the do’ers. The scrum master shouldn’t score, and product owner/analysts shouldn’t score. Just the do’ers.

What do you do with the points/scores?

You track your daily burndown, and your “velocity” per sprint. More on that later.

Just remember, think of stories as being scored by points. Or bananas. Or stars. Just not hours 🙂


Agile: Priorities

Agile .. priorities…

what are they?

The product owner or people driving your features/bugs/issues of your scrum team need to set priorities of your stories. How do they do that? Simple:


Now here is where it gets crazy. People always ask: What is high? What is low. Stupid question.

1 is low. 5 is high. numbers just work out that way. I find it funny going into a project or team or whatever and they are like, it is priority 1!!!!! really? so 1 is higher than 5? What crazy math are you using? 5 is higher than 1. Always. Just do it.

Anyways, the product owner set’s the priority. 5, 4 – you pretty much always score/do first. 3/2, get to when you can, and 1, well, those are wishlist/nice to haves, and you get to whenever. They usually sit in the backlog forever.

What happens when you have multiple product owners or you do stories for multiple product owners? Well, they set the priorities of the stories. If there is someone above them, they might over rule. There might be a “steering” committee meeting or prioritization meeting to set priorities of all the stories in the backlog.

The team/scrum master shouldn’t be guessing on what to do, the priorities need to come from somewhere above or someone driving the project from a business perspective.



Whatever you choose, your stories need to have priorities, and they need to be set by the right person.


Agile: Bugs

Agile can make things work for your process, you can get a ton done, but one question everyone has is “What about bugs?” or “What about things that come up during the sprint?” Oh noes!! Agile can’t handle it.. Agile will fail us.. fear not..

  • If you can, wait till next sprint
    Of course, if you can wait, wait. Don’t interrupt the current sprint, don’t get in the way of your do’ers focus, wait on it, assess it, analyze it, verify it, validate it, make sure you understand it instead of jumping in quickly and screwing something else up. Most times unless it is a HUGE showstopper, you *can* wait.
  • If you must, handle it. Swap something out
    If you can’t wait, then you should swap something out. You can’t just keep adding things to the current sprint, you will overfill your capacity. You need to swap something out. If this is a critical bug, it must be more important than *something* on your current sprint (that you haven’t started yet). If you are near the end of the sprint, then wait till next sprint.
  • If not a bug, but a request – First Option
    if it isn’t a bug, but a high priority request, you know the ones, from the president or god or you know. Well, then the first thing you can do is go to that user and say “Hey, we can do this, but we are going to move something out of the sprint that you requested.” If they say “Hey, no way, I want it all done”, then you respond “That isn’t the way it works, you need to move something out to move something in, or you need to wait and see if we get ahead where we *might* be able to pull something in, is that acceptable?” and then you think to yourself “someday these users will learn to think farther out than 2 days in front of their face”
  • If not a bug, but a request – Second Option
    So if you get this “god” request that *must* be done, but the user doesn’t have any existing stories to pull out, well here is what you do. You need to find a comparable story from someone else to pull out, and then you have to get that person, and the requester together and ask “Hey person we already committed to, is it ok if this other guys request bumps you out of the queue/sprint?” and if the person is ok with it (they usually are) then you can swap, if not, well, tough luck to the late request, they need to wait. (You can see from this process you need to learn to say “No”.
  • Last Resort
    the last resort, and I hate this option, but it seems it usually is the one that gets done the most. You just do the request. You fit it in, you work late, you do something different or something else takes a hit. The person gets there request, but no one learns from the process, since they think they can still request anything at anytime and get something from you, instead of learning to plan out a bit.

I’m sure there are infinite permutations of things you can do and situations you need and will need to deal with. The above is just a broad look at some the more recurring situations.

What you can learn from Bugs or Requests that need to be done *now!* is this:

There is always a way to adjust and handle things. Nothing is written in concrete. “Responding to change over following a plan”


Agile: Sprint

The sprint. The timeline of an agile team. The sprint is the “timebox” that you use to get your stuff done. It’s an iteration as you want to keep having sprints over and over.

You might have many sprints make up a release, you might have one sprint make up a release.

Your sprint could be a number of different timeframes.

I suggest 2 weeks.

Why 2 weeks? Well, it is enough time to get things done, but not have too much to worry about, it also ensures that things you want to get done are done in a small enough time frame so that the people that needs to see your outputs don’t have to wait longer than 2 weeks. 2 weeks also fits nice as 4 weeks could almost be considered 1 month.

Other alternatives? 3 weeks – might be the only other time frame I would suggest using, but then remember, if you have something get requested before a sprint, and you can’t get it into the current sprint, you won’t see that story completed for 6 weeks!

1 week is too short, you are just constantly churning. 4 weeks is another one that some teams use, but again, it could be 8 weeks before seeing something. The world just moves to fast for that kind of timeline.

Other options are doing staggered sprints. 2 2 3 2 2, or 2 3 2 3 2, etc. It can get confusing, but doable, I haven’t seen a reason to do it yet, so I have kept to the 2 week timebox.

I also recommend starting on a Tuesday, Wednesday, or Thursday. If you run your sprints say, from Tuesday, 2 weeks, you end up ending on a Tuesday afternoon. Same with Wed/Thurs. And you can do your Sprint Planning on that Tuesday/Wednesday/Thursday. When you use Friday and Monday, things just get tough to plan around. You probably never want to release on a Friday, people like to take vacations and days off on Fridays, tec.

Another tip, don’t treat a sprint like a mini-waterfall project. You will end up in trouble. Try to test/validate completed stories as they get completed by the do’ers. Waiting until the end of a sprint will lead to pile up of things to do.

Throughout the sprint, the product owners and requester of features should be in the loop (for one, with the Daily standup) but also they should be seeing the fruits of your do’ers labor, they should be seeing the output and features as they are completed.

Releasing at the end of the sprint is key. If you can’t, then you should at least have things in a “potentially shippable” state so you can demo and test it for the people that have requested it.

Other things you can do with your sprints. I like to separate out things into their own “mini sprint” when needed. An example might be, Upgrading your infrastructure to SQL Server 2008. You can’t really work on things on your servers when they are being upgraded, so at the end of a sprint, say “the next week is a mini sprint for the upgrade” and then pick up your regular sprint schedule after that. Same thing with holidays. Over the Christmas and New Year holiday you may have a 2 week holiday sprint. Just let your do’ers do research or something fun they have wanted to do. Most people will be out of vacation anyways.

Treat your sprint though like you would treat your daily standup. You don’t (you really can’t – or it screws up things) want to keep adjusting your days and length very often. The more you adjust the more it confuses people and the harder it is to try to get your actual velocity.

Pick a date to start, pick a timeframe, and stick with it. Try to stick with it for a year, at least 6 months before totally changing things up. Discipline, just like the daily 15 minute standups. Keeping things standardized and set helps your team and others know the schedule and keep things on track.


Agile: Daily Standup, Daily Scrum

I hate meetings. Really, I do. They are toxic.

But one of the things your team needs to do is meet daily. With agile, it’s called the daily standup or daily scrum meeting. But what is it?

  • Every Day, 15 minutes
    The meeting needs to be every day. Every day (Monday-Friday). No Exceptions. No days off, no skipping, no excuses. Schedule it every day. 15 minutes. Try to get it in the same place
  • Stand up
    The reason it is called a “standup” meeting is that you need to actually stand up. Why? Because sitting down makes people take their time. Standing up makes people move faster, because they don’t want to stand for 60 minutes.
  • Three Questions
    What I did yesterday? What am I doing today? What’s in my way? Simple enough
  • Not Everyone
    You want your do’ers there, you want the scrum master and product owner, maybe some others, but not everyone needs to talk. Go around the room and the do’ers should give an update, others should just listen.
  • Details, but not too much
    Do’ers, when giving updates, should let team know what stories they are working on. If you use a virtual+physical board, you will have story #’s. Don’t just spout the numbers. Spout the numbers and the story title, and where you are at, maybe even burndown if you track that manually.
  • Keep on Track
    easy to get off track. Even with standing and whatever. Scrum master should make sure things keep moving. In, update, out, go. 15 minutes? Try to get done in 10.

Should you meet on your sprint planning day? I say yes.

What else does the daily standup bring us? Communication. Everyone should know what everyone else is working on, where things are at. People can’t hide. They need to give updates, they probably should have a good reason or be working on something else off sprint if they have no update.

What else does it bring? In my eyes: Discipline. Making sure you know what you did, what you are doing, and always meeting at the same time, and doing the same thing every day brings a little discipline to the team. Keeping things on track, 15 minutes, cruising through updates, instead of meeting speak and 60 minutes of babbling. It does good for everyone. It lets your do’ers get on with their day so they can keep burning down points!


Agile: Backlog

The product backlog. Not a ton to say on this right now, but here are some thoughts.

  • The current sprint is not backlog
    Seem’s obvious. But the backlog is the backlog. The current is sprint is what you are focused on and working on.
  • The next sprint is backlog
    yes, the next sprint, on your board, is still backlog. It is somewhat solidified, but it is in flux until when you start the next sprint as your current sprint.
  • Your backlog should be semi-full
    having nothing in your backlog means.. well, you have no backlog, and that isn’t good. You should have enough stories for 1-2 sprints. Having no backlog is like living paycheck to paycheck.
  • You should prune old stories
    Older stories that have been just living in your backlog, should get pruned. Either they are higher priority and should get done, or they aren’t worth doing. They might resurface later as something but they shouldn’t be carried along for months/years if they aren’t important enough to do.
  • Priority matters
    The product owner should make sure they have the backlog prioritized. An backlog that isn’t prioritized is just a stack of cards.
  • Split Backlog into buckets
    I like to split backlog into buckets. Technical vs Product, maybe Features vs Bugs, some way to differentiate things.
  • Try to get as much as you can scored
    You might want to try to score as many stories in the backlog as you can so you are always ready. Of course there is a balance. You want a full backlog, you don’t want 5000 items, and you don’t want to take 3 days scoring things. Score enough so that if you do get ahead you can take stories from the backlog to work on. Try to avoid scoring outside of sprint planning sessions.

The backlog is one of the most important parts of your Agile process. Without a backlog you don’t have anything to focus on as you move forward through iterations. Try to think of it as a well, a well you don’t want to dry up, but you don’t want to overflow either.

My preference is to have a product backlog and technical backlog. That ensures that technical debt isn’t ignored, but separates concerns as far as features that you might want to implement.


Agile: Stories

In Agile, there is the concept of “stories” or “User Stories”. What are stories? Well, maybe it is best to look at what they aren’t:

  • They aren’t projects
    Stories are smaller than projects, by a long shot. A group of related stories is called an “Epic” but even then an “Epic” isn’t a project. But again, it all depends on how you or your organization defines a “project”. An agile team can focus on one project throughout their entire lifetime. Another might work on multiple projects, it all depends on how things are set up. But stories aren’t projects. Projects are made up of stories.
  • They aren’t tasks
    Stories should be bigger than tasks. Each story should really take a few to many tasks to complete. You can get into the mindset of breaking up everything into tasks, but then you might be going to granular. You want your stories to be small enough to get completed within your sprint, but also big enough to not take 10 minutes to complete.
  • They aren’t direct requests
    What do I mean by direct requests? A direct request from and end user or customer doesn’t directly relate to a story, it usually ends up being multiple stories. In the case where the request is just one story, it probably should be reworked to fit the mold of a story.
  • They aren’t features
    They might be feature requests, but like “direct” requests, usually a feature request ends up being multiple stories, or if the request is small enough to be one story, it needs to be reworked to become a story.
  • They aren’t bugs
    same as direct requests and features.
  • They aren’t day to day operational actions
    Some people might get into the mode of “well, we do this every day, so it should be a story”. No… it shouldn’t. It should be what you do day to day. Your velocity will get adjusted by your do’ers doing things day to day, but you shouldn’t storyize day to day things. Would you create a story for your commute? For reading email? For lunch? The only thing you might want to storyize is an architecture type meeting, where the deliverable is a bunch of stories. I like the idea but I’m not 100% sold on it yet.

Well, so there is a short list of things stories aren’t. So what are they?

As a user/group/xyz, I would like new feature/bug fixed/thing done, for this reason/business value.

I would say the most key part of that story format is the end. The business value. Without that you are spinning your wheels, you don’t know why you are doing something.

What about things that go along with a story?

You might write the # of a record in your virtual system to easily correlate. Depending on your process, you might hand write cards (I personally like this method). Or you might print them. What about other notes? As a developer or do’er you might write things on the back of the card for when you pass to QA or the validation of the story, or just to keep things in the open. If you use a virtual system, you might have extra notes or background info so the do’er can actually do it.

I like to have a small title, and then the story.


As a sales executive, I would like to be able to see my sales and goals by product and year so I can better analyze my commissions.

A title might be “Adding goals/sales to cube for sales”

I also like to have a “component” when working on a team with multiple mini projects that might be getting done. “Sales Cube” might be a good component for the story above.

What else do stories have? Priorities and Scores. More on that later..