3 ms·
> after I realized the tight relationship between epics and documentation Could you elaborate a bit on that? I'm curious what you discovered in that regard.
by eterps 6y ago
> after I realized the tight relationship between epics and documentation
Could you elaborate a bit on that? I'm curious what you discovered in that regard.
- btown 6y agoNot the parent poster but: Imagine you have an elaborate user flow diagram for a complex workflow. Every state/page a user could find themselves in, the outbound transitions perfectly match all cases of what someone might want to do. Now, these transitions end up quickly becoming stories: "A user in state X should be able to do Y." And you can bundle those together like "A user should be able to cancel and return to the project screen from any step of the wizard." Alternately, you can separate things by teams like "An API exists to cancel the reservation in progress, releasing the underlying inventory" vs. "A user can cancel the reservation in progress using the API" vs. "Factor out cancel buttons into a UI abstraction" if you want people to be able to pick those up and show progress independently. But fundamentally all this stems from an underlying plan, that flow chart from which all these stories flow. That plan is the epic. But that plan can't just be a frozen flow chart; it needs to be a living central repository of documentation, ideas, and mockups. Ideally, you have few enough of these epics that you can maintain things in the tools they're meant to be in: a Clubhouse epic, for instance, could simply link to the top-level Notion table of contents for the planning process for that epic. But if you're pulled in a billion different directions and have a massive feature surface, having this all in one place, alongside the chat related to that feature, with live references to the ongoing action items, would be incredible. Whether Kitemaker solves it or someone else, there's amazing work still ahead here.
- cloverich 6y agoBasically everything btown said but just to add my own POV -- we do this whole PRD - eng spec - implementation dance, and then comes maintenance, oops we missed a few things, or didn't think about this. All those things end up in separate tools and very rarely make it easy to keep it all together, esp. without a great PM. Having a better way to link documents to actionable (tickets) and back, along with conversations that happen along the way, would be incredibly powerful. There's no shortcut for organization and I doubt a tool will ever solve it all, but I think the combination of wiki+task manager+interactive chat is utterly begging for a (good) unified tool that makes it easy to document, chat, and work tickets in the same place. I imagine the end result wouldn't be automatic quality documentation, but more like an automated blog of what stuff your company is shipping. People wanting to catch up (for context, new teamates, etc) can kind of peruse recently completed features and pick up a ton of context, or search specific ones and build a good understanding of how it was implemented (and why). It seems it would lend itself naturally to a culture of documented, intentional communication, rather than the splattering of slack messages and random tickets I see so commonly. If anyone has interest in working on this, happy to join up. Its high on my list of "want to" side projects.