Iteration Planning Checklist

My company recently completed our most recent iteration planning session. It was an eye-opening experience for most of our team had not been part of an iteration planning session before. Below is a checklist that teams can use to help ensure that their iteration planning meeting is successful.

Before the session:

  • Product backlog has been finalized
    • All backlog items have been assigned a stack rank by the Product Owner
    • All backlog items have been assigned their story points by the Project Team
  • Project Team has been prepped
    • Team has been trained on basic Scrum processes/roles
  • Situation has been analyzed
    • Outside factors have been reviewed and impact on team has been documented
    • Project team member capacity has been evaluated/documented
      • # of hours per day for each worker
      • # of days each worker will be available during the iteration
  • Meeting logistics have been finalized
    • Meeting location has been booked for the entire day
    • Project team has been made available for the entire day
    • Lunch has been ordered

During the session:

  • Session was initiated
    • Welcome team to the meeting
    • Review iteration planning process
  • Backlog is triaged
    • Tasks are defined for each user story
      • Task duration estimates are documented
      • Task owners are documented
  • Agreement is reached
    • Project team and product owner agree on the plan of attack
  • Meeting is evaluated
    • What went well and what could be improved

After the session:

  • Iteration tracking system is set up
    • Allow tracking of all iteration tasks
  • Daily scrum meetings are set up

Following the steps above should help make your iteration planning meeting your most successful yet. Do you have any other tasks/items that you feel contribute to the success of your iteration planning meeting?

Top Three Reasons Scrum Doesn’t Work

You have likely heard many reasons why you should ditch waterfall methodologies for managing your projects and adopt Scrum instead. However, the following three situations are going to guarantee that scrum will not work at your company.

1) Lack of management buy-in

In order for scrum to succeed within your organization you need to have the support of management. Scrum processes and artifacts are quite different from what most managers/executives are familiar with. If your management team is not comfortable with the new process then they are likely to become an impediment (albeit an unwitting one).

Solution: If you want your management to be onboard with scrum and even champion it to other executives; you need to provide them with ammunition. In this case, the ammunition is knowledge; knowledge of the scrum processes and examples of companies which have successfully used scrum to improve their project success rate.

2) Not empowering the team

Scrum works only when the project team is empowered to use their insight and experience to make the appropriate decisions. Treating the team like a bunch of children (like many project managers do) does not motivate the team to perform to their best ability. You need your team to work at 100% and use their creativity and passion to push the project to completion.

Solution: As the scrum master you need to focus on serving the team rather than leading them. Your primary mission is to make sure the team has what they need to succeed. As the old saying goes “Give a man a fish…” well, you know the rest.

3) Viewing Scrum as a light-weight methodology

Many teams jump to Scrum because they feel that it is an approach to a project that just lets them code/build/etc. and not have to worry about processes or documentation. The teams that adopt Scrum because of this misconception are doomed to fail in their adoption of Scrum and in the execution of their projects.

Solution: Set realistic expectations that Scrum is just as rigorous as traditional methodologies. While traditional methods require a great amount of documentation, they usually offset this by reducing the amount of time the developers are in meetings and the amount of communication the team is required to create. Scrum on the other hand may reduce the initial documentation expectations, but it requires the team to be available and increase the frequency and immediacy of communication. This can be a big change to developers who sometimes camp in front of their monitor for a day or two at a time and do not talk to other team members.

Conclusion

While the challenges above are legitimate ones, they are by no means insurmountable. I have provided some basic ways you can counter the bad habits and situations you may encounter. Scrum is a powerful tool for creating change within an organization/project and the effort to implement it is well worth it.

    What is an iteration?

    One of the basic components of scrum is the use of iterations to plan work.

    What is an iteration?

    An iteration is a defined time period that is spent delivering a working product.

    How long does an iteration last?

    Most scrum iterations last from 2 to 4 weeks although some teams use shorter iterations. The goal is to define a time period that allows you to complete enough work to have working code ready for stakeholder review.

    What happens during an iteration?

    During each iteration, all the tasks of the software team occur. Requirements are being defined, code is being written, and testing is being performed.

    What inputs are needed for an iteration?

    In order to have a successful iteration, you need to have your team and product backlog fully flushed out. This will allow the team to hit the ground running.

    What are the outputs of an iteration?

    The outputs are fully-written and fully-tested code. The team will often demonstrate the working product at the end of each iteration and needs to be ready in case the stakeholders decide to ship/deploy the product.

    Five ways to build trust as a Scrum Master

    How many of you have worked with someone you simply didnt trust? How did this impact your work?

    • Were you less likely to work hard for them?
    • Were you less likely to share news with them?
    • Were you more likely to complain about them?

    If the answer to any of the above is yes, then you can see what trust is important in the workplace.

    Even more so, trust is vital during agile projects. Projects can ill afford to have employees not motivated to do their best for their teammates. Likewise, they can ill afford to have team members in the dark to potentially important information.

    Scrum Masters do not often arrive on a project with the trust of the team in place. You have to earn it. Sounds good, but how do you earn trust. Below are a few tips to help you gain the trust of the team.

    1. Tell the truth – sounds simple, but is often easier said than done. Tell the team the truth even when it hurts you. The team needs to know that they can believe what they are told. You are the primary source of information for the team and they need to know that they are hearing accurate information.
    2. Fulfill your obligations – when you say you are going to do something, do it! You expect the team to do this, so you better be prepared to live up to this standard yourself. This applies to the huge tasks (pushing back on requirements, gathering new resources) as it does to the small and mundane tasks.
    3. Be available – don’t hide from your team. If the team knows where they can find you, they know that you will be there to help them and the project succeed.
    4. Don’t hog the glory – everyone likes to be praised, but make sure you let your team be the ones to be praised. Since you are the one often speaking to the stakeholders (and bosses), make sure that you make it clear that the team did the heavy lifting. This will cause the team to get the recognition and they will respect you for not trying to take the credit.
    5. Be good at what you do – most people think that trust is only your attitude,but it also ties into your aptitude. If the team is to trust you as the scrum master, they need to believe in your ability to perform the job.

    Practice these five steps at all times. If you do, your team will trust you more and your projects are more likely to succeed.

    Please share other tips you have to build trust with the team.

    What is a burn down chart?

    What is a burn down chart?

    A burn down chart is a visual representation of the work remaining during an iteration. It tracks the amount of work committed to for the sprint along the vertical axis and the time (usually the 3 or 4 weeks of the sprint) along the horizontal axis. This work can be the number of user stories outstanding, but I prefer to use the number of story points that still have to be completed.

    Why should I use one?

    You should use a burn down chart so that all project stakeholders (team, product owner, management) can see the progress (hopefully) that the team is making. The chart also allows you to easily see how well the iteration is progressing. If the graph is moving from the top-left to the bottom-right, then work is being completed and your iteration is accomplishing its goals. If the graph is staying even, or heaven forbid moving up, then you know your iteration is in danger of not being successful.

    How do I create a burn down chart?

    The easiest way to create a burn down chart is to leverage one of the many Excel templates that can be found online. These templates allow you to enter the amount of work remaining for the iteration every day of the sprint. Once you have updated the data points, the graph will automatically update.

    What are story points?

    When the team is reviewing the backlog and planning their sprint, they will begin to undertake the process of estimating for each user story so that they can define the work that will take place during the sprint.

    Many developers and teams have extensive experience estimating how long coding a requirement will take. Traditionally this has taken the form of estimating how many hours it would take to code each requirement…and traditionally this method did not work very well.

    Scrum varies the formula by asking that the team assign story points to each user story. These story points are a measure of the complexity of each story. They do not attempt to assign duration to each story, but instead allow a comparison between tasks.

    You may ask why you shouldn’t assign hours to a user story. The reason is simple…each developer codes at a different rate. Having the team assign hours to a story assumes that they all can code at the same speed. Also, by estimating the complexity of each story, you have created a way for the team to analyze the stories from a more abstract vantage point. This can help to reduce bias during the estimating process.

    What is stack rank?

    For those of you new to Scrum, the term stack rank is an unfamiliar term.

    However, to Scrum teams, and Product Owners in particular,  stack rank is known..and very important.

    Stack rank is the traditional method Product Owners use to rank/prioritize their product backlog items.

    When you are adding items to the product backlog, simply associate a value for each item.

    There is discussion about what values to use for ranking items, but an effective method is to use a 1 to 3 scale. The scale is as follows:

    1 – System/process must support this user story
    2 – System/process should support this user story
    3 – System/process could support this user story.

    Now, prior to each Sprint planning meeting, review/update your backlog and item stack ranks. This will allow the Scrum team to focus on the most important user stories. In turn, this will allow the team to deliver maximum value on the project through all Sprints.

    Is Scrum just for IT?

    I had a conversation the other day with a coworker about Scrum. She was intrigued by the premise, but had always thought of Scrum as being a tool of IT teams. I explained to her that Scrum is not only applicable to IT teams, but to teams working on all types of projects.

    Project management in general was initially used by construction teams and engineers. It later became adopted by teams working on projects in every possible discipline. If you were to ask people 25 years ago about project management, most people would respond that it was only for construction projects. Now, if you were to ask people about project management they would reply that it can apply to projects in any area of business.

    Scrum, meanwhile, began in the arena of software development. Developers and project managers realized that their projects were not as successful as they should be and were looking for a methodology to improve their chances for success. They discovered that trying to meticulously plan all aspects of a project in advance was difficult if not impossible. This is due to the fact that the requirements and inputs to deliverables are constantly changing. As a result, Scrum and other agile methodologies were created. They allow for a greater degree of freedom in reacting to change.

    This prevalence of change is not limited to software development projects. Any construction team can tell you that clients are always changing their specs (tile vs hardwood, deck vs patio, etc.). Likewise, marketing departments are always changing their marketing initiatives (print vs online vs television). It is this abundance of change that makes Scrum perfect for teams working in any area of a company. Scrum lets you adjust to change quickly while delivering maximum value to your clients.

    Now how precisely should you follow Scrum within your team? This depends on your team’s individual situation, but all teams can take some aspects of Scrum and apply them to their projects. Below are some of the features/ideals of Scrum you can incorporate into your next project:

    Scrum Meetings

    • Conduct monthly planning meetings to determine to tasks/deliverables to be completed that month
    • Conduct daily update meetings among team members
    • Conduct monthly review/demonstration meetings to show your stakeholders the progress you have made
    • Conduct monthly retrospective meetings that can be used to improve processes within your team/company

    Scrum Roles

    • Scrum Master – person who is responsible for facilitating the project and removing impediments from the team’s path.
    • Product Owner – person who is responsible for representing end-users to the project team. Helps to prioritize work.

    Scrum Ideals

    • Communication is more important than documentation – work with your clients to determine their needs and then work to deliver a product that satisfies them
    • Client feedback is better than inflexible requirements – when a client comes back with feedback, don’t immediately dismiss the change. Work with them, within reason, to update the product/process

    In conclusion, Scrum has benefits that transcend departments. Just because IT folks developed the process does not mean that it is extremely technical or is only applicable to IT projects. Most projects in the real world are subject to changes in their environment and changes to the project itself. Scrum helps projects teams adjust to change in an effort to deliver maximum value to the client.

    Good luck on your next project and hopefully Scrum can help your team succeed.

    Introducing Scrum to your team

    Imagine the first day of school…waiting with your mom at the bus stop and getting ready to board the bus and head to school. The moment was filled with both eagerness and anxiety. Learning that your team is adopting Scrum can have that same mix of emotions for your team members.

    Your team is going from a world where:

    • they were instructed step-by-step on how to act by the project manager
    • they were given clearly documented rules/requirements
    • their parents (project manager) were often judged on successes/failures

    To one in which:

    • they get to determine their success
    • they are forced to collaborate on their work
    • they are accountable for success/failure

    There is a lot of change involved in migrating from a waterfall to an agile methodology. Some team members are going to be upset because they will think that the shift in methodology is because they couldn’t succeed using the previous schema. Some team members are going to be concerned with how their jobs change. Managing this change will play an integral role in how your team succeeds.

    In introducing your team to Scrum, you should focus on the following:

    • What Scrum is
    • Why your team is adopting Scrum
    • What Scrum means to the team

    What Scrum is

    The first step in introducing Scrum to your team. This site deals with scrum and agile, but the two article below are more directed towards those new to Scrum.

    Why your team is adopting Scrum

    Next, you need to explain to your team why your company is adopting Scrum. You need to focus on the benefits of Scrum to the team because it is a huge change for them.

    • Increased quality
    • Improved time to market
    • Higher customer satisfaction
    • Increased responsiveness to change

    What Scrum means to the team

    To the team members, Scrum means:

    • More power to make collaborative decisions
    • Greater visibility to company decision-makers
    • Greater chances to make great products
    • Potential for greater camaraderie

    Remember, moving to Scrum is a big change…and a big opportunity for improvement. Do your best to make your team excited about the new process.