Articles

Please enter an article title, author, or keyword
Product Backlog Rules of Thumb

While working with Product Owners over the years I have learned some rules of thumb that help make their Product Backlogs more manageable. Some of these rules of thumb I learned from other people and some were learned through trial and error.

Remember that the statements contained in this article are just rules of thumb intended to help guide your management of a Product Backlog. They are not rules to adhere to no matter what. Always use common sense when applying a rule of thumb to your particular context.

TechWell Contributor's picture TechWell Contributor
Group Coherence for Project Teams - Continuous Improvement

One of the principles in the Agile Manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This principle guides both aspiring and seasoned Agile teams in the pursuit of continuous improvement and can support whatever Agile adoption path an organization may choose. Kent Beck adds observations about this topic.

TechWell Contributor's picture TechWell Contributor
Speaking Ill of the Dead

The title alone should generate imagery ranging from destructive rumors to the macabre. Who are these dead, and who is speaking ill of them? "The dead" are former team members, the ill speakers are those who blame problems on them, and we are taking a critical look at this complaining with just a touch of irony. We are talking about the culture of blaming current problems and challenges on team members who are no long with the team for whatever reason. Almost anyone who has been involved in the software development life cycle has experienced this behavior, and very possibly taken part in it even with the best intentions in mind.

TechWell Contributor's picture TechWell Contributor
ScrumBut: Failure to Deliver

In this article, Michele Sliger discusses one of the more common "ScrumBut" practices that, while allowing teams to say "We suck less," isn't really in keeping with intended Scrum practices. This ScrumBut practice is the persistent failure of the team to complete the agreed-upon features in the iteration or sprint.

Michele Sliger's picture Michele Sliger
Deception and Self-deception in Software Testing

Untruths about software testing are common. Managers, programmers, and other people on software projects don't always mean to deceive. Quite often, they fool themselves into believing what they want to believe. But sometimes they lie deliberately and even pressure testers to lie. And testers can also practice deceptions and self-deceptions of their own. In this column, Fiona Charles describes four categories of common deceptions and self-deceptions in testing and outlines what testers need to do to address them.

Fiona Charles's picture Fiona Charles
If Your Build Fails and No One is Around to Hear It, Does It Make a Sound?

Continuous Integration build tools are great: they help us ensure our product works after every commit, keep historical data and metrics, build our product for all target environments, and do many more useful things. But there's one key aspect that often gets overlooked: They're fun.

Daniel Wellman's picture Daniel Wellman
Tips and Advice - Retrospectives
Podcast

Tips and Advice - Retrospectives

Bob Payne's picture Bob Payne
Distributed Agile Day to Day

"Distributed" isn't a word that always has appeared favorably in works about agile methodology. After all, the proximity of agile team members while working is highly regarded. In this article, an excerpt of which originally appeared in the May 2009 Iterations eNewsletter, Chris McMahon takes a look at how "agile" and "distributed" can work together successfully.

Chris McMahon's picture Chris McMahon
Moving into the role of Scrum Master - Jill Tubaugh
Podcast

Moving into the role of Scrum Master - Jill Tubaugh

Bob Payne's picture Bob Payne
Three Strategies for Task Allocation

Iteration and release planning are keys to successful agile projects, but overall have a relatively small impact on a developer's day-to-day life, compared to the daily planning that takes place each morning. The strategy a team uses to sign up for work has significant implications for what a developer's day will look like, impacts his work style and habits, and ultimately can significantly impact the overall success of the iteration. Unfortunately, the agile community gives relatively little guidance in this area. In this article, I will share my experiences with three strategies for task allocation, drawn from several typical agile projects with two to three week iterations.

Robert Williams

Pages

Upcoming Events

Apr 28
Jun 02
Sep 22
Oct 13