Like many who have wanted to learn more about Scrum and Agile Project Management, I have immersed myself in my studies. I have increased my knowledge in the area through books, websites, and other blogs. Below are the links to other resources I have found useful.
Please suggest other resources that you have found useful in learning more about Scrum.
What is a daily scrum meeting?
The daily scrum meeting is a meeting where the scrum team meets to provide a real-time update on project status.
When does the meeting occur?
As the name implies, the team meets every day during the sprint for the daily scrum meeting. The team should aim to conduct this meeting at the same time every day.
How long does the meeting last?
The daily scrum meeting should last about 15 minutes.
The entire scrum team should attend. This includes the scrum Master and the team (developers, testers, etc.)
What happens at the meeting?
During the meeting each team member answers three basic questions:
- What did you do since the last meeting?
- What are you going to work on today?
- Is anything preventing you from accomplishing your goal?
What are the goals of the daily scrum meeting?
- To provide a real-time project status update
- To alert the Scrum Master of any impediments that he/she may have to remove from the team’s path.
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.