So you have your product backlog chock-full of sprintable items. User stories, dev chores, a few bugs—all estimated, of course, right?!? Your team is ready to rock, so where do we start? We start with my favorite scrum thing: the Sprint Planning Meeting.
Humility is a highly valued trait in our team members at Atomic Object. This is best exemplified when Atoms admit that they do not know the answer to a question—something I drive for when interviewing developer candidates. How they respond can tell a lot about how good of a fit they will be. Is their […]
When you’re trying to get started on your first agile/scrum project, it’s easy to find arguments about why it’s a good approach. But it’s a lot harder to find clear, step-by-step explanations of the tools and processes you need to succeed. I’m trying to fill that gap by answering the question: How do you estimate […]
I encourage all of our Delivery Leads to measure how effectively they are managing their backlog through the lens of three goals. These goals can be phrased as the following questions: Do you have four to six weeks of sprintable stories at the top of your backlog? Is your backlog completely estimated up to your […]
Talking about risk is hard. Over the past couple years, I’ve adapted an approach from the book Waltzing With Bears by Tom DeMarco and Timothy Lister.
Anyone new to web development can be overwhelmed by the unending supply of choices for tech stacks. Teams just getting started in the industry lean toward something easier to pick up and learn. Teams coming from other platforms such as embedded or desktop dev tend to stick with tools and languages they’ve always used.
The best process is owned by its team, but everyone has to start somewhere. That’s why I drafted this, a template for Atomic Object’s Agile process. It’s designed to be a starting point for our maker teams as they come together to tackle a new project.
Agile backlogs should be oriented to a client first, team second, and product last. At Atomic, our teams range in size from two to eight developers. Teams larger than eight generate too much communication overhead and require too much effort to manage the backlog.
Anyone who’s led a product engineering team knows that a growing team requires investments in process, communication approaches, and documentation. These investments help new people get up to speed, become productive quickly, stay informed about what the rest of the team is doing, and codify tribal knowledge so it doesn’t leave with people. One thing […]
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)