- 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.
I think every agile team should be viewed as a small startup. When you do so, you can begin viewing senior leadership largely as venture capitalists (VC). They’ll occasionally visit your office, they’ll provide valuable expertise and insights that will help your small company succeed, they’ll paint a vision of your competitive landscape so you can make better choices, and most importantly, they’ll infuse your small startup with cash. This metaphor can only be extended so far, and we could talk endlessly about the complexities of decision making within this model, but we won’t. Instead, I’ll borrow a quote from Martin Fisher:
Knowledge is the process of piling up facts; wisdom lies in their simplification.
So how do we simplify this? How can we paint a simple view to understand which decisions are for our VCs to decide, which is for the start up’s leadership, and which is for those in the trenches turning ideas into working product? Here’s how I answer those questions: