In the second part of this three-part series, I'll cover some common process terms you'll hear working on your first custom software product.
I propose that we stop measuring throughput or velocity. Instead, companies should empower software teams to make value estimates on individual work items.
In this third part of my Rethinking Agile series, instead of adding practices, I recommend something for you to remove. That is, stop estimating effort!
Surprisingly, the process of software development offers a helpful framing for finding the answer to life's big questions.
A month or so into an engagement, we came across a story that took much longer than our estimate suggested. This experience made us reevaluate the backlog.
In a previous role, I took any chance to better understand how my product could satisfy the needs of my market. A beta release provides that opportunity.
Sometimes, it's hard to see progress on a software project. Here are three problems I’ve been able to solve by making work more visible.
In today's entry in my series on Agile Practices for Normal Life, we'll dig into the backlog with a focus on defining and estimating our stories.
Thanks for following along as I adapt agile software practices into "normal" life! Today, we’re going to talk about building a non-software-related backlog.
The software backlog is everyone’s main hub for information, and it should be more than a giant to-do list. Here are 5 questions your backlog should answer.
Have you run into a technically-focused backlog item with little definition? Follow these four steps to manage expectations and find success.
The Remaining Work field in Azure Boards helped our scrum master keep our distributed development team from becoming blocked.