The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.


Standing Room Only

Posted by admin under Scrum Discussion

I just ran across this post ( called “How Many Chickens Are Too Many?” on InfoQ, in which Vikas Hazrati reports on a rather lively discussion that occurred recently on the Scrum Development group. The discussion in question was triggered when one user posted that as many as four to five “chickens” attend his team’s daily standup. Given that his team only consists of five or six individuals, the ratio of mangers to developers is nearly 1:1.

Now, most Scrum literature clearly advocates that if a manager—or “chicken” as Scrum practitioners are fond of referring to them as—wants to attend the daily standup, he or she may do so as a silent observer. The daily standup is a meeting designed for inter-team communication. That is, it’s an opportunity for the team to speak with one another frankly about how the sprint is going. When managers are present, teams may skew the reality of their progress to present a rosier picture of development for them. Or worse yet, the manager may simply usurp the daily standup, using it as a time to micromanage the team. When this happens, Scrum’s emphasis on self-organization—that is, the team’s ability to choose how it will accomplish its sprint goals—is effectively undermined and management reverts back to a traditional, command-and-control approach. In my mind, the issue is clear. A manager should probably not attend the team’s daily standup meetings, but, if it’s essential, he or she should do so as an observer only.

Interestingly, many of the Scrum users who weighed in on the conversation claimed that this is not exactly a black-and-white scenario. Several explained that it depends on the particular culture of the organization. That is, if management is supportive of its developers and empowers them to make decisions (even if they’re occasionally the wrong ones), then there’s no harm in them attending this meeting. Of course, few of us have had the good luck to write software in such an environment. It’s far more likely that your manager or Product Owner is not exactly hands-off.

What do you think? Obviously, Scrum is designed to be flexible so that it can adapt to the needs of specific organizations. But should something as fundamental as this really be up for interpretation? I’m curious to hear your thoughts on this one.

Tags: , , , ,


Scrum Meetings

Posted by admin under Scrum Basics

Sprint Planning Meeting

In Scrum, every iteration begins with a sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. This meeting is a time-boxed conversation between the Product Owner and the team. It’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments.

When the team agrees to tackle the work, the Product Owner adds the corresponding stories into the sprint backlog. We usually recommend this be physically represented by moving a Post-It note or index card with a story written on it from the backlog into the sprint backlog.

At this point, the Product Owner may choose to leave while the team decomposes the forecasted backlog items into tasks. This meeting is sometimes called Sprint Planning Part 2.

In Large Scale Scrum, multiple teams pull items from one Product Backlog. Multiple backlogs for one product, and multiple Product Owners lead to localize suboptimizations, longer work-in-progress queues, thus are harmful to agility.

Watch an example Sprint Planning Meeting.

The Daily Standup

Every day, the Scrum team gathers in front of their taskboard to discuss the progress made yesterday, goals for today, and any impediments blocking their path.

  • What have I done since the last Scrum meeting (yesterday)?
  • What will I do before the next Scrum meeting (tomorrow)?
  • What prevents me from performing my work as well as possible?

This meeting should not exceed 15 minutes. If members of the team need to discuss an issue that cannot be covered in that amount of time, we recommend they attend a sidebar meeting following the standup. This allows team members to attend meetings that directly involve their work, instead of sitting through irrelevant meetings. Unfortunately, daily Scrums often last longer than 15 minutes. To compensate, many teams use stop watches or timers to uphold the time limitations. Also, to limit distracting small talk, many teams employ a talking stick or mascot, which a team member must hold to speak in the meeting. Upon finishing an update, the talking stick is then passed to the next team member, who reports, and so on.

Watch an example Daily Scrum Meeting.


Sprint Review Meeting

When the sprint ends, it’s time for the team(s) to demonstrate a potentially shippable product increment to the Product Owner and other stakeholders. The Product Owner declares which items are truly done or not. Teams commonly discover that a story’s final touches often excise the most effort and time. Partially done work should not be called “done.”

This public demonstration replaces status meetings and reports, as those things do not aid transparency. Scrum emphasizes empirical observations such as working products.

In Large Scale Scrum, multiple teams demonstrate a single integrated product increment.

Watch an example Sprint Review Meeting

Sprint Retrospective Meeting

After the sprint review meeting, the team and the Scrum Master get together in private for the retrospective meeting. During this meeting, the team inspects and adapts their process. When the Scrum Master and outer organization create an environment of psychological safety, team members can speak frankly about what occurred during the Sprint and how they felt about it. After all team members thoroughly understand each other, they work to identify what they’d like to do differently the next Sprint, typically focusing only on one or two specific areas of improvement each Sprint. The Scrum Master may also observe common impediments that impact the team and then work to resolve them.

Overall Retrospective Meeting (Large Scale Scrum only)

In Large Scale Scrum, the Sprint Retrospective is followed by an overall retrospective that focuses on inter-team interactions and the outer organization.

Watch an example Sprint Retrospective Meeting.


Tags: , , , , , , , ,

Scrum Training Courses