Why Estimate Bugs and Chores in Your Backlog?

When we’re running a client’s project using our Atomic Process, our team will assign an estimate of points to each item in the product backlog.

In general, we classify backlog items into three buckets:

  • Features (new or enhancements)
  • Chores (dev work not resulting in tangible product changes)
  • Bugs (fixing unexpected behavior or regressions)

Read more on Why Estimate Bugs and Chores in Your Backlog?…

Where to Begin? – Two Tools for Starting a Project with Intention

Starting off on the right foot, with organization and intention, can be the first differentiator between a successful and unsuccessful project.

More often than not, the beginning of a project can feel like standing at the edge of a precipice. It’s an unknown. You’re given a statement of work (SOW) detailing the goals for the project, the budget, and some background. Then you’re faced with all the questions of how to get to those goals. Where to begin? Read more on Where to Begin? – Two Tools for Starting a Project with Intention…

Stop Making Sprint Commitments!

I’ve become convinced that for most Agile projects, making sprint commitments is the wrong thing to do. I was happily surprised to find out that I’m in good company here—the 2011 Scrum Guide actually removed the word “commitment” in favor of the word “forecast”.

I have three reasons why I’d suggest you stop making sprint commitments and start making sprint forecasts instead. Read more on Stop Making Sprint Commitments!…

Negotiating Your Project Management/Development Approach with Clients

During the sales process, it’s really easy to spend all of your time talking with clients about their software needs while ignoring questions of process. But so often it’s organizational differences that causes all of the headaches. Clients often lack the authority to make quick decisions, have competing priorities, or are blocked by IT policies. This can present real challenges and perhaps some unpleasant surprises for agile teams once development starts.

Read more on Negotiating Your Project Management/Development Approach with Clients…

Conquering the Perils of Distributed Teams

We live in a world where co-location of team members is less and less common. Whether your organization is contracting out pieces of a project or has embraced the reality of telecommuting, there are some dangers that you should be aware of. For example, email and chat are handy forms of communication, but they leave much room for interpretation. And keeping a team operating efficiently across physical and even artificial boundaries can be very challenging, especially as project pressures rise. Read more on Conquering the Perils of Distributed Teams…

Why is Your Team Falling Behind? Ask ‘The Penny Game’

One of the chief concerns of a software development team is managing work. We even have our own jargon—user stories, tasks, chores, bugs, epics, sprints—terms we use to help juggle assignments and stay organized.

But even a smart, hard-working team full of disciplined developers can fall behind, failing to meet deadlines and feeling overwhelmed by everything that needs to be done. To understand why work piles up like this, it helps to look at a different but similar industry: manufacturing. Read more on Why is Your Team Falling Behind? Ask ‘The Penny Game’…

Don’t Let Silos Ruin Your Software

Dividing up work is a natural and proven way to solve most problems faster. Specialization is also common, especially in areas that demand a range of skills too broad for anyone to master fully. Both of these approaches can be useful, but just like ammonia and bleach, if you aren’t careful to keep them separate, bad things can happen. I’m talking about the dreaded silo, the bane of engineering projects. Read more on Don’t Let Silos Ruin Your Software…