Are your teams retrospectives really worth the effort? Do the problems you identify actually get solved? If not, your team might need some help learning how to use retrospectives to continuously improve. This article illustrates how Scrum teams can continuously improve by using a combination of their definition of done, working agreements, and the product backlog.

The most ignored attribute of development is reviews. Many Scrum teams compromise on review tasks in order to complete their other tasks in a particular sprint. Though they plan separate tasks for reviews, they frequently ignore them. In reviews themselves, the most ignored is the code review. The shorter the sprint, the less the importance and time allocated to code reviews.

We all understand that Scrum teams should be self-managed and self-organized. Empowered is the commonly used term, because without empowerment it's difficult for self-management and self-organization to happen.

Mitch Lacey discusses the difficulty surrounding software project estimation, and provides tips and tricks for using two agile software estimation techniques when estimating projects.

In Scrum, we depend on the team for estimation. It is the team that estimates the efforts and time for each product backlog item; it is the team that, in the sprint planning meeting, breaks down each item into tasks and estimates efforts for each; it is the team that, in the daily Scrum, estimates the remaining efforts. . . .

By conceiving the project from the beginning as an agile project, you can outsource projects effectively and agilely. This paper describes how one team used Scrum to create an agile RFP, discusses what information should be present in an agile RFP and proposes how to find a partner to trust through a lean, Agile selection process.

It's difficult to change learned behavior, and even harder to change group habits. This is one reason why it is difficult establish Scrum Most companies understand that Scrum has a lot of potential and bears the chance to shorten time-to-market or the delivery of high-quality software, but. . . . And there we go again: "Scrum, but. . . ."

The story of how using Scrum helped one team complete a project outside the world of software with a minimal budget, almost no direction, and even less time.

Scrum teams just look different. From their faded whiteboards to their discarded post-it notes, Scrum teams make their mark just by doing their job. Read one CSPs story of how his team's space tells the story of their struggles and their triumphs.

This article discusses the details of burn down and burn up charts: which units to measure, how to adapt to scope variations. He gives some guidelines on how to interpret burndown charts. He reminds that the chart should be objective and visible.