Goals probably ought to precede work items

If you use sprints, that’s fine, even if I don’t think they’re the apex of effective work organization. I subscribe to “continuous all the things,” and sprints get closer to that than working on something for six months before coming up for air does.

In almost every place I’ve worked at in my career, teams filled their capacity with as much work they thought they could get into a sprint, and then they’d look at the work and come up with a goal. The only reason I don’t think ChatGPT came up with those goals is that it hadn’t been released yet.

Does that seem… backwards?

Wouldn’t a team have something they were trying to learn or deliver, set that as the goal, and then name work items that would work towards that goal?

Then, if you achieve the goal sometime before the two weeks are up, you could declare victory and pick a new goal. Or you might learn before the two weeks are up that the goal isn’t worth pursuing.

Do that fast enough and with manageable enough chunks of work, and you’ll be in for a real shocker: what value did the two-week time box provide?


Like this message? I send out a short email each day to help software development leaders build organizations the deliver value. Join us!


Get the book!

Ready to learn how to build an autonomous, event-sourced microservices-based system? Practical Microservices is the hands-on guidance you've been looking for.

Roll up your sleeves and get ready to build Video Tutorials, the next-gen web-based learning platform. You'll build it as a collection of loosely-coupled autonomous services, developing a message store interface along the way.

When you're done, you'll be ready to contribute to microservices-based projects.

In ebook or in print.