Everyone wants more project documentation, but nobody wants to write it. Make the most of your time by only creating the documentation you really need.
The Why of a story is more important than the What. To prioritize a story, people need to understand why they're supposed to build it in the first place.
Do your blockers explain what needs to happen next? Or who's responsible for it? Or when it's due? If you want them to get done reliably, they'd better.
Systems integrations are hard. Following these do's and don'ts will go a long way in de-risking the project, minimizing surprises, and finding success.
Keep up with our latest posts.
We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.
Formal code reviews lead to confusion and wasted time. Pair programming, on the other hand, has regular, effective code reviews built into its framework.
A good consultant identifies a problem and helps resolve it. A great consultant listens and identifies options, but ultimately yields decision making power.
Describing expected behavior in a story is a baseline. Make your stories even better by writing a story goal that describes the purpose of the feature.
Agile stories should focus on outputs, empowering the dev team to implement behaviors as they see fit. Keep them small and free of arbitrary distinctions.
Ready to build your agile backlog? Start with the user interface. By breaking your UI into features, you end up with a manageable list of bite-sized tasks.
