4 ms·

The biggest problem I have with all those tools which imply that requirements are part of the ticket is that at some point you have no idea what your product lo

The biggest problem I have with all those tools which imply that requirements are part of the ticket is that at some point you have no idea what your product looks like. I have seen so many times when a change is planned that does not take into account some of the use cases, because you have no visibility into those cases - they are buried somewhere in the hundreds of closed tickets. Once feature is released, the broken part is suddenly discovered and in the best case fixed few months later. In worst case buried as an open bug in the backlog. When you start something new, it's not a big deal. Everybody loves to work on something new. Nobody loves working on legacy products, because they don't have enough documentation and full of bugs, driving up costs of support and becoming a pain in the ass of some CIO. Yet somehow all those fancy new tools focus on creating great experience for building something new. Plenty of decent software was written in the last 50 years, but we are burning the money, electricity and silicon to replace it, because we could not come up with methods and tools for building on top. Why it is always about integrating something like requirements and context into planning? Why not doing it the other way, integrating planning into requirements and context, being product-centric rather than work-centric?

kevsim 4y ago
This is very insightful feedback. Thank you for that! One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker. Thank being said, your comment has my gears turning on how we could do an even better job of it.
- ivan_gammel 4y ago
  Well, having it on a work item is a "no go" for me, it is an approach that solves one job by sacrificing many others. As a scaler CTO, I always think about how this information can be discovered and used after the work is done, maybe in 2-3 years, in bigger and more structured team, by different people. Recording it with the work means that you can never be sure, that there's no overlap with some other unit of work elsewhere, which could have made some parts of spec obsolete or replaced. Finding connections to other cases recorded in other units of work is also difficult. For those reasons I always define requirements in a wiki or documentation management system, where you can look at all current requirements at glance and, if system supports versioning (it must), at all requirements at any given moment of time too (audit, incident investigation). From the requirements we can go into tasks and related code, if needed, but for product development it is more important to be able to see the full picture than when it was done. Implementation tickets just link the relevant parts of the spec, but never quote it or substitute it. Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.

kevsim 4y ago

This is very insightful feedback. Thank you for that! One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker. Thank being said, your comment has my gears turning on how we could do an even better job of it.

ivan_gammel 4y ago
Well, having it on a work item is a "no go" for me, it is an approach that solves one job by sacrificing many others. As a scaler CTO, I always think about how this information can be discovered and used after the work is done, maybe in 2-3 years, in bigger and more structured team, by different people. Recording it with the work means that you can never be sure, that there's no overlap with some other unit of work elsewhere, which could have made some parts of spec obsolete or replaced. Finding connections to other cases recorded in other units of work is also difficult. For those reasons I always define requirements in a wiki or documentation management system, where you can look at all current requirements at glance and, if system supports versioning (it must), at all requirements at any given moment of time too (audit, incident investigation). From the requirements we can go into tasks and related code, if needed, but for product development it is more important to be able to see the full picture than when it was done. Implementation tickets just link the relevant parts of the spec, but never quote it or substitute it. Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.