What a Burn down Chart Can Say

From :http://www.methodsandtools.com/archive/scrumburndown.php

What a Burn down Chart Can Say

There are only two lines drawn in Burn down chart, but the situation they describe might have different reasons.

Ideal Team

Such diagram indicates the great team able to organize itself. The team is not over-committing and finished the spring backlog on time. The team is also able to estimate capacity correctly. No corrective action is necessary in such case.

Great Team

Such progress might be observed on charts of experienced teams. The team has completed work on time and met the sprint goal. They also have applied the principle of getting things done, but the most important is they have adapted a scope of the sprint backlog to complete the sprint. At the end the team has a possibility to complete some additional work.

In the retrospective, the team should discuss the reasons of late progress in the first half of the sprint and solve issues so they are better in the next sprint. The team should also consider the capacity that they are able to complete.

Nice Team

This is a typical progress that can be observed in many experienced agile teams.

The chart says again that the team was able to complete their commitment on time. They adapted the scope or worked harder to complete the sprint. The team is self-reflecting.

The team should discuss change of plan immediately as they see the progress has been slowing down from the beginning of the sprint. Typically it is suggested to move a low priority item from the sprint backlog to the next sprint or back to the product backlog.

Boom. It Is Too Late.

This burn down chart says: "You have not completed your commitment".

The team has been late for the entire sprint. The team did not adapt the sprint scope to appropriate level.

It shows that the team has not completed stories that should have been split or moved to the next sprint. In such situation the capacity of the next sprint should be lowered. If this happens again, corrective actions should be taken after a few days when slower progress is observed. Typically, lower priority story should be moved to the next sprint or back to the product backlog.

Boom. Too Early.

The team finishes its work sooner than expected. The stories were implemented, but the team didn’t work on additional stories even it had the capacity to do it.

The stories were probably overestimated, therefore the team finished them earlier. Also the velocity of the team has not been probably estimated correctly.

Let’s Have a Rest

The team with such progress has a problem. The problem is either the team committed to less than they are able to complete or the product owner does not provide enough stories for the sprint.

The reason might be also an over-estimation of complexity, which ends up in completion earlier than expected at the beginning of the sprint.

Oh, Management Is Coming!

The team is probably doing some work, but maybe it does not update its progress accordingly. Another reason might be that the product owner has added the same amount of work that was already completed, therefore the line is straight.

The team is not able to predict the end of the sprint or even to provide the status of the current sprint.

Such team should be stopped after two or three days that shows a flat the line of progress and should immediately apply corrective actions.

Do Your Duties

The team is non-functional on many levels. To fix this situation the team should restart. Restart from scratch by training and do a retrospective to figure out why this is happening.

Zero Effort

A chart like this indicates that stories or tasks were not estimated during the sprint planning meeting and the sprint has not officially started yet.

To fix this situation, team should immediately arrange a planning meeting, estimate the user stories, include them in the sprint according to their velocity and start the sprint.

Up to the Sky

The first sprint typically looks like that. It is good source of knowledge because the team has failed significantly and it is highly visible.

Stories or tasks were added into the sprint backlog every day without any progress recorded. Another reason might be that tasks were re-estimated constantly during the sprint.

The mistake is that the team did not identify the problem that the chart displays.

The sprint backlog should be reevaluated and rearranged immediately. The coach might be helpful, as an experienced Scrum master and product owner should often facilitate this situation.

Bump on the Road

The team has not started sprint correctly. They added stories after the sprint had started. It is positive that they recognized that planning is missing planning, it is however too late. The team should be careful about the capacity estimation as planning happened in the middle of the sprint, not before it.

In such case it is suggested to restart the sprint, even within a shorter timeframe.

Progress from Long-Run Perspective

Burndown charts described in previous paragraphs are description of iteration. But does a nice Burndown chart indicate a great team? Maybe if your team indicates great progress for more than one iteration. Does the team believe in such success? I would be personally careful. We all know about changes coming every minute. Maybe the team provides conservative estimation for their safety.

Management usually takes care about the improvement of velocity, sprint by sprint. Please, do not expect that. Velocity is not an indicator of the team. Velocity is not a KPI by which you should measure your team. Velocity is just capacity planning tool. Nothing more, nothing less. Asking people to accomplish more story points in iterations will result in stories that have more story points estimated without real reasons. It could be name as "Story points inflation".

Agile: Tips for Running An Effective Scrum Meeting

1. Keep the meetings on target

The first step towards an effective Scrum meeting is making sure that the meeting stays on target. In order to do this, the only subjects that should come up during this time are what each individual team member is working on as well as the issues they’re struggling with.
In order to get this information across, many suggest that each team members stick to answering these three questions, and only these questions, during the daily Scrum.

1. What did you do since the last meeting? Team members comment on whether or not their commitments from the previous day were met.

2. What will you do today? Team members explain what they’re working on today and will have done by the daily stand-up tomorrow.

3. What issues do you have? Team members explain where they are running into trouble with certain aspects of the project.

Your team should answer each of these questions when it is their turn, and they should do so without your prompting. If they do miss one of the questions, make sure you get an answer before moving on to the next person. Only by answering all three questions will the team have a true understanding of what everyone is doing.

2. Meetings should not be about problem solving

One important thing to note is that for the daily Scrum meetings to be effective, problems can’t be solved during the meetings. While the third question brings issues to the forefront, these issues may not affect the whole team. As a result, spending an excessive amount of time discussing these issues with everyone is not a productive use of team time. Call “parking lot” and table the issues for the time being. After the daily stand-up, schedule a problem-solving meeting with the individuals who these issue effect. Such an approach will allow for targeted issue resolution.

3. Team members should be prepared ahead of time

As mentioned in the discussion of the three questions, your team members should be able to answer those questions without your prompting. In order for this to happen, you must outline what you expect to hear from your team every day. Once you set those expectations, your team members should come prepared with answers on a daily basis. Reward those who do, and take aside those who don’t. Explain how being prepared with these answers helps the team, and ultimately the project, stay on track.

4. Make the meetings short

Daily Scrums that run too long aren’t effective. People get distracted, stop listening, and ramble on for far too long. Your team then begins to resent these meetings, and communication breaks down. That’s why limiting your meeting time is so important. The shorter they are, the more likely people are to pay attention and find them necessary.
For an effective meeting, the daily stand-up should run about 15 minutes. Some use the formula of 2n + 5 minutes where n is the number of individuals on your team. Either way, by sticking to the 3-question rule, your team will get all the information they need within these time restrictions.

5. Stand Up Meetings

Some believe that, by forcing everyone to stand during the daily Scrum meeting, the meeting is more likely to stay on target and on time. And let’s be honest, the reasoning is solid. No one wants to stand around for an hour just talking.
By asking your team to stand, you’re showing a commitment to staying on task, and your meetings are more likely to be effective because of it.

6. Don’t wait for everyone

Did you say that the Scrum meeting started at 8:30? Then start it at 8:30. If you wait for everyone to show up, you’re wasting time and the meeting automatically becomes less effective. Start the meeting when you said it would begin, and allow people to trickle in.
This doesn’t mean that you should allow people to get away with showing up late though. Offer incentives for your team to show up on time, or embarrass those who showed up late. Ask anyone who comes in after the meeting start time to announce why they were tardy. No one likes to be called out repeatedly for being late. Other option? If they’re not on time, make them wear a dunce hat for the day. It’s not a fashion statement that everyone’s comfortable with.

7. Make sure the meetings are daily

When you’re running daily Scrum meetings, make sure that they’re just that – daily. This is important for consistent communication between team members about what is and isn’t being accomplished.
If these Scrum meetings are run infrequently, minor issues tend to be overlooked, pile up, and amount to larger issues down the road. Consistent communication is key to making these meetings as effective as possible in getting the program running.

8. Have Rules About Who Speaks and When

During the Scrum meeting, only one person should be speaking at a time. They should have the floor, and only be interrupted when they’re getting off of topic. (Oftentimes, when they do, someone will yell “Rat Hole” as a reminder to stay on topic.) Allowing people to speak freely ensures that everyone is heard and that there is no miscommunication.
Along these lines, only the ScrumMaster and team members should be speaking during the daily stand-up. While stakeholders are more than welcome to attend, any issues they have should be taken up with the ScrumMaster after the meeting has adjourned. Allowing more than the vital team members to speak almost guarantees that the meeting gets off topic, and runs much longer than necessary. You are more than capable of presenting a stakeholder message to the team.

9. Remote workers should be part of the daily Scrum

Just because remote workers aren’t physically there with the rest of the team, this doesn’t mean that they shouldn’t participate in the daily Scrum. They can conference call in, or even better, video chat during the daily stand-up. Of course, there are logistics involved with planning this, as you have to take into account several time zones. Make sure that you’re not asking a team member to participate in a Scrum meeting at an unreasonable time (as in 3 AM their time).
Keeping remote workers involved is good for team morale, as well as for project advancement. Asking them to dial in once a day ensures that your team is working as a team, and that issues are addressed.

10. Don’t let your team focus on the ScrumMaster

While the ScrumMaster is running the meeting, this doesn’t mean that the team members should only look at you  when speaking. They need to be looking at their team, as this is team communication time.
If you’re a ScrumMaster who notices that your team is speaking to you instead of their other colleagues, step back from the circle, and stand off to the side. This will force your team to speak to one another instead of you. The project will then take on more of a communal feel, communication will increase, and the meetings will be more effective.

11. Meetings should be tech free zones

As tech professionals, we’re all attached to our devices. The daily Scrum meeting is one place you have to enforce the parting of ways though; don’t allow your team to bring their laptop or phones to the meeting. We know just how easily it is to get distracted by these devices, and an effective Scrum meeting will never occur while people are playing Angry Birds on their cell phones.
At the end of the day, the keys to running an effective Scrum meeting are ensuring that your meeting stays on track and on time. In order to do this, have rules about what can and cannot be talked about, make sure that your team members communicate with one another, and that technical devices aren’t welcome. If you do these things, your daily stand-ups will be more effective, and you’ll help produce a better product because of it.

Agile: Daily Stand-up

What are daily stand-ups?

Daily stand-ups is adopted by agile team to provide a status update to team and to continuously improve the team velocity by meeting up daily and talking about:

• What were accomplished since the last meeting.
• What will be taken up before the next meeting.
• What obstacles are preventing progress.

How to make the daily stand-ups effective?

If not given proper attention to the daily stand-ups it would end up being just a waste of time without any value to the team or the project. It is always nice to talk about the effectiveness of the stand-ups so as to make it more interesting and generate value to the team and the project. Few tips to make the stand-ups effective are:

• Stand up. Do not sit and do the daily "stand-ups"
• Each member should time-box the status update to 30 - 60 seconds.
• Stick to the point and take lengthy discussions separately.
• Conduct stand-ups same time and place every working day.
• Avoid postponing stand-ups.
• Better to choose a place near the workstation unless it do not disturb other teams and avoid meeting in conference rooms. This is to avoid situations where the conference room is already occupied and delay the meeting.
• Each member take a few minutes preparing what to say during the meeting.
• Everyone should be on time.
• Pass around a token (e.g. a soft ball) so that the holder gets the turn to talk.
• Let the member choose an appropriate time to conduct the daily stand-up.

Who should attend the daily stand-up?

Ideally everyone involved in the team should attend the daily stand-ups. If it is the inception phase of a project, it would be really good if the stakeholders could also attend the daily stand-ups. If not everyday, weekly involvement would help them know the progress of the team. It also helps the team get constant feedback and know about new initiatives and promotions taken by the stakeholders that might impact them in one-way or the other.

When do daily stand-ups become inevitable?

Stand-ups is a really nice practice that motivates and pushes the team forward, but sometimes it just becomes the most wasted time of the day even if you are doing it right. The reason could be that it is done by a relatively small team where everyone share the same work-space and know what the other person is up to. The team could collectively decide to do avoid the daily stand-ups and do a weekly iterations instead.

Stand-ups becomes inevitable when:

• A team member spends significant amount of time in other projects.
• Team are spread across departments or location.
• The team size is pretty large (6 and above).
• Inception of the project where there are lots of unknown variables.
• There's lots of confusion within the team.
• A new member joins the team and is not aware of the work done by the team and also help in knowing other team members.

Agile : Nice Chart

Agile: Scrum Roles and Responsibilities

Agile techniques have become very popular and effective approaches to delivering benefit on a project.  For this reason, we will focus on Agile frameworks, techniques, principles and ideas as well.

Agile SCRUM is one of many Agile frameworks.  SCRUM is a very specific framework that focuses on the following roles.

1. ScrumMaster
2. Product Owner
3. Team
4. Stakeholders

The following graphic depicts each role and the relationship of the role with the other SCRUM roles.

A depiction of the SCRUM roles, each roles primary responsibility and its relationship to the other SCRUM roles

The ScrumMaster Role

The ScrumMaster, despite popular belief, is not the Agile term for a project manager.  In fact, the ScrumMaster serves a very different purpose.  The ScrumMaster does not have responsibility for delivering the project.  Rather, the ScrumMaster is a facilitator, coach and champion of the Scrum framework and process.

The biggest challenge to applying Scrum within an organization is not the actual Scrum process.  It is the cultural change and acceptance of the new roles that an organization finds most difficult (e.g., the enhanced power of the Team to commit to a Sprint goal, and to deliver it with little interference from “management”).  More on the differences later, but because the organization does need to accept a significant change in philosophy, there is a need for a ScrumMaster, who serves as the coach, mentor, facilitator, champion, and cheerleader.

Adopting Agile Scrum framework is as much about a change in philosophy as it is a change in processes.  This is because Agile Scrum places distinct responsibilities on each of the roles.  Agile Scrum does not allow anyone to play more than one role.  And the tension among the roles is there for a reason — almost like a balance of power among the roles so that no one role has an unfair authority over the other roles.

It is for the above stated reasons that a full-time ScrumMaster is recognized as the authority on Scrum and needed to continue to facilitate and champion the process, to ensure that the process is followed as intended, and to coach members as needed.

Specific ScrumMaster responsibilities include the following:

• Communicate the value of Scrum
• Teach the organization on Scrum to maximize business value
• Facilitate Sprint Planning, Daily Scrums, Sprint Reviews and Retrospective Meetings
• Create the Task Board and Sprint Burndown Chart at the start of every Sprint
• Attend all Scrum meetings
• Preserve the integrity and spirit of the Scrum framework
• Maintain the focus of the Team
• Make the Team aware of impediments and facilitate efforts to resolve them
• Serve as a coach and mentor to members of the Team
• Respectfully hold the Team, Product Owner and Stakeholders accountable for their commitments
• Continually work with the Team and business to find and implement improvements

The Scrum Team (Team) Role

The Team is ultimately responsible for committing to a Sprint goal and promising to deliver it within the timeboxed Sprint.  The Team is self-managing and self-organized.  The Team works with the Product Manager to determine what items from the Product Backlog they can deliver in a Sprint.  They Team decomposes the Product Backlog into a series of activities that must be accomplished as part of the Sprint.  Since the Team commits to the Sprint, they must ensure that they can deliver on what they promised.  Sprints cannot be extended or delayed.  So the Team wields great power, but the Team is also held accountable for delivering on their commitment.

Specific Team responsibilities include the following:

• Commit to, and self-organize, around a Sprint Goal (A Sprint Goal is different from the Sprint activities.  The Sprint Goal is the intended spirit and purpose of the Sprint.  So if the Team realizes in mid Sprint that a required activity for the Sprint is missing, the Team should add the activity to the Sprint so that they can deliver the Sprint Goal)
• Work with the Product Owner to analyze and decompose the Product Backlog items
• Help create and maintain the Sprint Backlog, Sprint Burndown Chart and Task Board
• Demonstrate the product at the end of each Sprint — during the Sprint Review
• Implement action items that come out of Retrospectives (essentially lessons learned)
• Facilitate Sprint Planning, Daily Scrums and Retrospectives if the ScrumMaster is not able to do so for any reason
• Attend all Scrum meetings
• Collaborate and share knowledge and experience among the Team, Product Owner, ScrumMaster and Stakeholders
• Help other members of the Team
• Look for ways to continually improve

The Product Owner Role

The Product Owner is responsible for delivering product value.  This means working with the Stakeholders to understand their needs and developing a Vision and a Product Backlog that aims to achieve the Vision.  This role might be the closest role to a classic Project Manager role.  However, there are still significant differences.  For example, the Product Owner does not control what the Team commits to completing.  The Product Owner prioritizes the list of items on the Product Backlog in sequential order (from 1 to n).  But the Product Owner cannot force the Team to commit to delivering beyond what the Team feels comfortable.  Since the Sprints are timeboxed (usually 2 weeks to 30 day Sprints), the Team is ultimately responsible for defining what they can deliver.

Specific Product Owner responsibilities include the following:

• Maximize business value by the Team
• Maintain and prioritize the Product Backlog sequentially (1 to n)
• Create and maintain the Release Burndown Chart
• Help the ScrumMaster organize Sprint Review Meetings
• Attend Scrum Meetings
• Clearly communicate the business case to the Team and Stakeholders
• Build and maintain a relationship with the Stakeholders
• Support the ScrumMaster to help the Team become self-organizing
• Report progress to the Stakeholders regularly
• Ensure the proper use of corporate resources and assist the Team to obtain resources as needed

The Stakeholder Role

The Stakeholder is anyone who has an interest or stake in the project.  This can be the direct managers of the Team members, the persons providing funding for the project, the Project Manager — yes I said Project Manager.  Combining Agile Scrum with traditional project management is not unusual.  In fact, Scrum does not account for many of the things often required for a project such as project management documents and artifacts.  This might be because of organizational policies and procedures that require a level of oversight that requires specific documents be created (e.g., Risk Management Plan, Quality Assurance Plan, Project Management Plan, Procurement Management Plan, etc.).  These responsibilities still fall under a Project Manager role.

Within the Scrum framework, Stakeholders are responsible for communicating their needs, and providing feedback on the product.

Specific Stakeholder responsibilities include:

• Work with the Product Owner to develop and maintain the Product Backlog
• Attend Sprint Planning meetings as needed to provide feedback and expertise
• Provide direct feedback to the Team during Sprint Reviews
• Remove roadblocks and impediments for the Team, Product Owner and ScrumMaster
• Avoid distracting the Team during a Sprint — after the Team has committed to the Sprint
• Support the Scrum Framework