3 ms·
> I was embarrassed that the release primarily made life better for our developers rather than for our users. Given the tasks I planned for a sprint, I identifi
by ukuina 1y ago
> I was embarrassed that the release primarily made life better for our developers rather than for our users. Given the tasks I planned for a sprint, I identified the ones that would be exciting and valuable enough to the user to include in the release announcement.
> I thankfully avoided ever writing another uncomfortable explanation of a release that offers nothing to the user.
Seems short-sighted?
This is marketing-driven development where you have "learned the lesson" that thankless maintenance and stabilization tasks should be avoided.
- miningape 1y agoI got the same impression, not having a snappy marketing tag line is nothing to be embarrassed about. Sometimes users just don't get it - and never will. Sometimes things are too technical to be useful to a user (the author touches on this themselves). Let the results speak for themselves - and be proud of your achievements, it sounds like this was a success. Focussing too heavily on user facing issues is a kind of myopia that actually leads to a worse user experience over time, and, ironically, a slower turnaround for those user facing issues.
- mtlynch 1y agoAuthor here. Thanks for reading! Considering the release announcement as part of sprint planning doesn't mean eliminating maintenance work. The release announcement is just the top N user-impacting changes in the release, so not every bit of dev work requires justification to the end-user. The lesson I learned was that when I have a maintenance-heavy release, I needed to ensure that we have at least some work that's user-facing that we can present to users in the release announcement.