Who here just started a new job? Or maybe you’re about to start a new job? This is the situation I recently faced. It’s stressful, and it was important to me that I make a strong, lasting, and positive first impression. In fact, let’s talk about that today, but before we do, I’d like to give a big shout out to rands. A decade ago, I ran into his blog. It was the first blog I ever followed, and his advice in Ninety Days is something I reread before I start any new job. In it, he suggests that the interview continues through the first ninety days on the job. I agree, and I can relate with his piece of advice here:
- Can data help our teams improve? If so, what kind of data?
- How do we responsibly use this data?
- Can metrics help the teams and the organization embrace a culture of experimentation?
- Data isn’t enough. How can we tie it to the motivations and passions of our team members?
Books like Mike Cohn’s Succeeding with Agile and Henrik Kniberg’s Scrum and XP from the Trenches were two of the first books I read as I began my agile journey. These books were useful to teach me about Scrum, but Scrum is simple to understand. People though? They’re a challenge. As Ronika Lewis eloquently put it:
The best books about Scrum aren’t about Scrum.
With that in mind, I thought I’d share some books that have made a difference in my professional life. You won’t see the words “Scrum” or “agile” in any of them, but rest assured they’re relevant to our domain. As a bonus, I’ve attached all passages that I highlighted as I read each book to give you greater context.
We spend a lot of our days talking about epics, stories, and tasks, and in many cases, we assume others understand these concepts as expertly as we do. Sometimes they don’t, and today I intend to take Leonardo da Vinci’s advice:
Simplicity is the ultimate sophistication.
Below you’ll find a table that boils epics, stories, and tasks to their most primitive forms, and it comes at a risk. Some may read this blog post and wish to prescribe these definitions on their teams. They shouldn’t. Others might argue details suggesting that one thing should be another. Today is for simplicity; details are for another day. For example, I write below that tasks should be no more than 8 hours, but what I don’t write about is the nuance:
- Tasks are for the team to find what works best for them.
- Tasks that are less than eight hours allow for team members to touch and advance a task every day.
- Such tasks also make impediments easier to spot when they’re not verbalized.
- Some teams choose not to decompose stories into tasks. That’s okay.
My point is that your mileage may vary, and as long as we clearly understand why we do what we do, then that’s what matters most. So without further adieu, here’s how I simply define epics, stories, and tasks.
As extra credit, feel free to also read about spikes and how they apply to agile teams.