Planning Poker provides an engaging way for the team to discuss implementation approaches and build consensus around the effort involved.
Here's a storytelling shortcut for better describing an idea, service, or product. Who's it for, what do they need, and what can we do?
Managing design work is typically less straightforward than development work and not always done as a traditional design backlog.
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.
Writing good stories sounds easy, but actually isn't. Here are some tips from a developer to help you write clear, effective user stories.
Storybook has benefits for teams working on front-end components. Make the most of these benefits by adding interaction tests for components.
Estimates are first and foremost for project planning. Eventually, as various team members get familiar with the codebase, disparities should fade away.
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!
We often apply metrics to job performance. When it comes to software development, however, this is surprisingly complicated.
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.
The 10-box exercise is an agile planning tool that helps the team visualize the sprint schedule and account for how the actual calendar impacts delivery.