With this in mind. It seems odd that a lot of agile developers build software around “user stories”. Seems to lead us right into the trap of imagining a users intentions.
Luckily I think the industry is moving away from user stories.
I don’t think this is relevant. It only seems odd if you believe that the job of developers is to please everyone rather than to make money. User Stories are reasonable for the goal of creating software that will make a large proportion of the target market want to buy that software. Numerous studies and real world evidence, show that the top few percent of products capture the vast majority of the market and therefore software companies would be unhappy if their developers did not show a clear bias. There would only be a downside if the market showed the U-shaped distribution and the developers were also split on this distribution potentially leading to an incoherent product, but this is normally prevented by having a design authority.
I think when you say, “I don’t think this is relevant” you mean… I agree with your premise (that user stories are related to the assumed intent bias) but I don’t think that we should upend user stories yet because they do what they are supposed to.
To which I agree.
Development is complex and realistically even with user stories, developers are considering other users (not in the narrative). If you were to take away user stories and focus on tasks, developers would still imagine user intent. By using user stories we are just shifting focus on intent. Which I think is usually a net positive. This post helped me illuminate in my head where it might not be a net positive.
Unless I misunderstand your comment, isn’t it rather the opposite of odd that user stories are so popular, given that this is what the bias would predict? That being said, maybe I’ve argued a bit too strongly in one direction with this post—I wouldn’t even say that user stories are detrimental or useless. Depending on your product, it may well be that some significant ratio of users to have strong intent. My main claim is that in most situations, the number of people who are closer to the middle of the spectrum is >0. But it’s not necessary for that group to dominate the distribution.
So in my view, it can still make sense to focus on a subgroup of your users who know what they’re doing, as long as you remain aware that this will not apply to all users. E.g. when A/B testing, you should expect by default that making any feature even mildly less convenient to use will have negative effects. So you should not be surprised to see that result—but it may still be the right choice to make such a change nonetheless, depending on what benefits you hope to get from it.
I may have not been clear. I am agreeing with the entire post. I agree with your comment too that “user stories” arose most likely for the same reason as this bias.
I also agree with you that figuring out intention is an important part of development. A majority of users will use my software with the same intent.
I just meant to say that I immediately thought of “user stories” while reading this post. My initial thought was that user stories focus too much on intent. For example, if you are hyper focused on the user trying to reset their password you may neglect the user who accidentally clicked the reset password button and just want to navigate back to the log-in page. Would there be benefit to removing the user story as a goal and just make the goal, create a reset password page? I agree with you though, user stories serve their purpose and might be more of a net-good. This post just helped me recognize a potential pitfall of them.
With this in mind. It seems odd that a lot of agile developers build software around “user stories”. Seems to lead us right into the trap of imagining a users intentions.
Luckily I think the industry is moving away from user stories.
I don’t think this is relevant. It only seems odd if you believe that the job of developers is to please everyone rather than to make money. User Stories are reasonable for the goal of creating software that will make a large proportion of the target market want to buy that software. Numerous studies and real world evidence, show that the top few percent of products capture the vast majority of the market and therefore software companies would be unhappy if their developers did not show a clear bias. There would only be a downside if the market showed the U-shaped distribution and the developers were also split on this distribution potentially leading to an incoherent product, but this is normally prevented by having a design authority.
I think when you say, “I don’t think this is relevant” you mean… I agree with your premise (that user stories are related to the assumed intent bias) but I don’t think that we should upend user stories yet because they do what they are supposed to.
To which I agree.
Development is complex and realistically even with user stories, developers are considering other users (not in the narrative). If you were to take away user stories and focus on tasks, developers would still imagine user intent. By using user stories we are just shifting focus on intent. Which I think is usually a net positive. This post helped me illuminate in my head where it might not be a net positive.
Unless I misunderstand your comment, isn’t it rather the opposite of odd that user stories are so popular, given that this is what the bias would predict? That being said, maybe I’ve argued a bit too strongly in one direction with this post—I wouldn’t even say that user stories are detrimental or useless. Depending on your product, it may well be that some significant ratio of users to have strong intent. My main claim is that in most situations, the number of people who are closer to the middle of the spectrum is >0. But it’s not necessary for that group to dominate the distribution.
So in my view, it can still make sense to focus on a subgroup of your users who know what they’re doing, as long as you remain aware that this will not apply to all users. E.g. when A/B testing, you should expect by default that making any feature even mildly less convenient to use will have negative effects. So you should not be surprised to see that result—but it may still be the right choice to make such a change nonetheless, depending on what benefits you hope to get from it.
I may have not been clear. I am agreeing with the entire post. I agree with your comment too that “user stories” arose most likely for the same reason as this bias.
I also agree with you that figuring out intention is an important part of development. A majority of users will use my software with the same intent.
I just meant to say that I immediately thought of “user stories” while reading this post. My initial thought was that user stories focus too much on intent. For example, if you are hyper focused on the user trying to reset their password you may neglect the user who accidentally clicked the reset password button and just want to navigate back to the log-in page. Would there be benefit to removing the user story as a goal and just make the goal, create a reset password page? I agree with you though, user stories serve their purpose and might be more of a net-good. This post just helped me recognize a potential pitfall of them.