With Scrum, you’re constantly focussing on:<\/p>\n
How does the application look \/ work for the user *right now*?<\/p>\n
…to the extent that you care more about “does this feature work for the user?” than “is the code\/art\/architecture for this feature ideal?”.<\/p>\n
We regularly get situations where a feature *appears* to work, to a casual observer – but on deeper inspection, it’s clearly broken in one or more significant ways. Sometimes, the “broken” parts are so obscure that you’d need help to even find them. Other times, they’re obvious if you try to to use the feature more than just once or twice.<\/p>\n
In Scrum terms, it’s pretty clear what’s gone wrong: the Product Owner didn’t describe the feature clearly enough (they implicitly included functionality they didn’t really care about, … or they described it too vaguely to be implemented well).<\/p>\n
Scrum’s in-built check\/balance against that is the Team. The developer who adopted the task should have rejected it during the Planning meeting, should have insisted on a clearer User Story (or a more explicit feature description).<\/p>\n
But in the real world, this stuff happens. Leaving the issue: What do you do next?<\/p>\n
Here’s an approach I’ve been experimenting with recently.<\/p>\n
When it happens, you split the feature description in half, re-defining one half as the part which is done + working, and the other half as the part which isn’t working. Or into 3, 4, etc – if there’s multiple “player visible” ways in which it’s not working.<\/p>\n
This seems to work pretty well – it lets us independently prioritise “the bit we’ve already got (hence: zero extra dev cost)” and “the hard stuff that’s not working”. And quite often, we end up redesigning some other part in a way that makes the broken edge-cases no longer exist – so we never need to fix them.<\/p>\n
…but I’m still experimenting with it. I’m sure we could do our Planning meetings better – both from the PO side (more detailed descriptions, more PO planning) and\/or from the developer side (more questioning, demands for more detail).<\/p>\n","protected":false},"excerpt":{"rendered":"
With Scrum, you’re constantly focussing on: How does the application look \/ work for the user *right now*? …to the extent that you care more about “does this feature work for the user?” than “is the code\/art\/architecture for this feature ideal?”. “It’s not done” … “but it looks done!” We regularly get situations where a […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,20,62],"tags":[],"_links":{"self":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/1701"}],"collection":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/comments?post=1701"}],"version-history":[{"count":0,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/1701\/revisions"}],"wp:attachment":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/media?parent=1701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/categories?post=1701"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/tags?post=1701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}