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.
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:
- 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 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.
- 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.
I was at a holiday party this past weekend when I began talking with a fellow guest. In a weird coincidence, we were both project managers. Naturally, we began to talk about our jobs and our experience with project management. And naturally, this topic quickly bored the other attendees of the party.
We focused the majority of the discussion on the environments in which we work. He works for a firm that is entirely waterfall in its methodology, while I work for a firm that utilizes both agile and waterfall approaches.
I began to sing the praises of agile, and Scrum in particular, to this person. I talked about how we are able to respond to customer needs quicker, adapt to changing requirements, and deliver a better product.
He stated that all of those benefits sound great, but his company would never allow a team to implement Scrum. I asked why that is. He replied that the management at his company views Scrum as being for lazy teams.
This reply upset me because I know that Scrum often receives this bad rap. Those of us who practice Scrum know that it is not for lazy teams. I explained to him that Scrum is not for lazy team for the following reasons:
- Lazy teams do not self-organize
- Lazy teams do not commit to aggressive timelines
- Lazy teams do not constantly look for ways to improve themselves and their processes
- Lazy teams do not hold themselves accountable
- Lazy teams do not respond to change in a positive manner
Scrum teams constantly do all of the above.
We continued to talk about the myth of Scrum being for lazy teams and he stated that he was going to try and convince his company into piloting a Scrum project. I told him that I would try to elicit more talking points for him to use when discussing the false myth of Scrum as the “lazy project methodology”. So, I ask you to leave a comment stating how you defend Scrum and fight the myth.
The definition of done is one of those things that drives businesses crazy.
During waterfall projects, the following definitions of done often get thrown around:
- Developers define something as done when they have completed the development phase of a project.
- Testers define something as done when they have tested the software and it passed all test cases.
- Validation/QA users define something as done when all the required paperwork is completed.
- Project managers define something as done when the client approves the deliverable.
How do we define “done” for agile projects?
Since scrum is more of an iterative process that requires all team members to complete their work during a given sprint, done means a combination of the above criteria.
For a given sprint, done means:
- All code has been written and checked in
- All features have been validated by the testers
- All features have been approved by the Product Owner
In essence, this means that a sprint is done when the product is ready for your end-users. This is one of the main benefits of scrum and agile development: once you complete each sprint you have a shippable product that you can release to your end-users. This allows you to deliver value to your clients more often and more effectively.
What is a product owner?
A product owner is the Scrum role responsible for representing the interests of the end-users of a given product. This role is often filled by the product manager of a given product, but can also be filled by other stakeholders or even a project manager.
What does a product owner do during a Scrum project?
- At the beginning of each sprint, the product owner is responsible for providing the product backlog (list of desired features/functionality) to the Scrum team.
- During the sprint, the product owner is responsible for providing clarity to the Scrum team when questions arise
- During the sprint, the product owner is responsible for ensuring that no additional features get added to the sprint backlog.
- At the end of each sprint, the product owner is responsible for reviewing and rejecting/approving the deliverables.
What makes a great product owner?
- Knowledge of what the customer needs/wants
- Basic knowledge of how software is developed
- Ability to manage all project stakeholders
Why aren’t there more great product owners?
Many people placed in the product owner don’t succeed for the following reasons:
- They are not the true owner of the product (features or profitability)
- They are not familiar with the Scrum process
- They are not able to dedicate enough time to the project
In conclusion, all successful Scrum projects have a product owner who understands the product and can commit adequate time to the project. If you are going to be a product owner, make sure you research what your customers need and how it will impact the bottom line of your company.
What is it?
Planning poker is a group estimation tool that is used to help the project team come to agreement on task duration estimates.
When should I use it?
Planning poker is performed during the Spring Planning Session at the beginning of each sprint.
What are the inputs for planning poker?
In order to play planning poker, the team must have the list of features to be delivered and a deck of planning poker playing cards.
What makes planning poker cards unique?
Instead of having values ranging from 2 through Ace, planning poker cards have values that are more conducive to estimating task durations. Typically these values are: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. These values correspond to the number of days a feature would take to develop.
Who attends a planning poker session?
Planning poker sessions usually are attended by a moderator, the product owner, and the development team.
What is the process?
- The moderator reads the description of the user story/feature the team is estimating. The product owner may provide clarification on the feature.
- Each estimator chooses a card from their deck that corresponds with their initial estimate of the development effort. Each estimator places their card upside down on the table so that they do not influence the other estimators.
- After all estimates are on the table, the cards are flipped over.
- If there is a significant range between estimates, the estimators who submitted the high and low estimates provide rationale on their estimate.
- Once the discussion on the range has been conducted, steps 2 through 4 are repeated until a consensus is reached.
What is the main benefit?
Planning poker’s main benefit is that is encourages open discussion about estimates. This helps the team reach a more accurate decision instead of relying on the opinion of one influential team member. It also allows the team to take advantage of the experience of all team members.
Where can I get the cards?
Planning poker cards can be purchased or made from scratch. Below are some links for procuring your own planning poker cards:
The Sprint Retrospective is one of the most valuable tools in the scrum arsenal. The retrospective is designed to help the team improve their processes and performance so that future sprints are even more successful than the one the team just completed. Implementing and embracing Sprint Retrospectives is a key to project success and improving the overall performance of your team. Below are common questions I have received about sprint retrospectives.
When does the meeting occur?
- At the end of each Sprint
- After the Sprint Review (demo) meeting with the Product Owner
- Before planning the next Sprint
How long should the meeting last?
- Most scrum practitioners suggest that you timebox the sprint retrospective to three hours.
Who attends the sprint retrospective meeting?
(note that the Product Owner does not attend the meeting)
What is the purpose of the meeting?
The team evaluates how the sprint went and suggests improvements to their process so that future sprints are even more successful.
What makes a Sprint Retrospective successful?
- All team members must feel comfortable providing feedback
- All aspects of the Sprint should be analyzed
- Tools used for development
- Tools used for communication
- Team composition
- Project logistics
- The sprint review must result in actionable items that will be implemented during the next Sprint.
In a previous post, we discussed the benefits of colocation to a scrum development team. Now that we have established why you want a war/team room, let’s dive into what your war room should entail.
A war room provides the following:
- a dedicated location where the team can work
- a location that is isolated from others within the business to reduce distractions
A war room has the following:
- Plenty of wallspace to hold whiteboards, corkboards, and other collaborative tools
- Plenty of electrical outlets to support all the computers, monitors and other electronic equipment
- Appropriate lighting (harsh fluorescent light is not ideal)
- Storage space for personal belongings (since team members will not have cubes to store their gear in)
- Small refrigerator to store soda or other beverages (reduces the need for runs to the kitchen or conveniene store)
- Appropriate temperature controls
A war room does not have the following:
- Walls or cubicles separating the team members
- Adjoining noisy neighbors or busy hallways
Those are the basics of what a war room should entail. If you have features that have worked well in your experience please leave a comment so that others may benefit.
Once the team has completed the development phase of the sprint, the next step is to conduct a Sprint Review.
What is a Sprint Review?
A Sprint Review is a demonstration of the new functionality to all project stakeholders. The meeting serves to alert stakeholders of the progress made in the sprint and to set the stage for the next sprint.
Who attends the Sprint Review?
The Sprint Review meeting is attended by the project stakeholders. These stakeholders include the:
- Product Owner
- Project Team
- Executive Sponsors (if applicable)
- Customers (if applicable)
Why conduct a Sprint Review?
The Sprint Review meeting is important because it allows you to follow one of the core principles of scrum – continuous feedback and iterative improvement. The Sprint Review meeting allows you to receive feedback on the functionality that was just developed. This helps you to ensure that you are on the correct path, or to help you get back on the right path if you were heading in the wrong direction.
What is the structure of the meeting?
A Sprint Review meeting is informal in nature. Teams should aim to not use a PowerPoint presentation. The meeting is designed to stimulate conversation and PowerPoint slide decks often serve to stifle dialogue. Instead, the team should converse with the stakeholders in an attempt to engage.
How long should the meeting last?
The meeting duration should correspond to the amount of functionality that was developed. In general, these meetings should not exceed an hour in length, and they often are as short as 10 minutes.
Who demos the functionality?
Do not feel obliged to have the ScrumMaster present the functionality every meeting. Anyone on the team is encouraged to give the demonstration.
As social media become more and more important to the lives of agile project managers and scrum masters, I thought I would provide you with a list of scrum subject matter experts to follow on Twitter. Click on the links below to explore their Twitter profiles. My profile can be viewed at http://twitter.com/cmcspiritt.
If you have any others you think I should include in the list, please let me know.