Taro Logo

How can I create solid standardizations for creating user stories that will drive impact?

Profile picture
Software Engineer at Startup Companya year ago

Right now I'm in a situation working for a startup that posts a video of a bug with little to no detail at all and sends it off to dev to be fixed. If there is information included, there is no standardization so it can be frustrating having to hunt this information down. I understand in startups I will have to learn to operate in a realm of ambiguity; however, the team is so small that I could potentially fix this with a little buy in.

Somethings that I've seen work in my previous job were having:
-screen shots of current state and future state
-video of current issue
-steps on how to reproduce
-device information
-potential solutions

Im new to the team and don't want to be "that" guy trying to change everything, so I don't want to come to them with any half baked ideas. Do you have an example of a strong story that I could use as a template for our tickets?

1 Like


  • Profile picture
    Robinhood, Meta, Course Hero, PayPal
    a year ago

    Improving the bug triaging process is something I'm very familiar with (I spent a lot of my career working closely with QA), so I have a lot of thoughts here. Before I go through anything though, I want to be clear that you should set your expectations realistically as you're working at a startup. A startup is going to value velocity above all else, and even if everyone wanted to refine a system, startups often don't have the infrastructure to do so. Adding process is often the enemy of speed as well - There's a good chance you won't get everything you want in this interaction.

    That being said, I imagine the process should be something like this:

    1. Figure out who is forwarding you these bugs - I'm assuming it's either a QA person or some project manager. Or maybe it's automated.
    2. Talk to the person from Step #1 and deeply understand their situation - In particular, figure out what kind of information they have access to. There's a good chance these bugs are lacking context because the surrounding information simply isn't there.
    3. Create a proposal to improve this process, weaving in your learnings from Step #2 - For example, if the person filing the bugs already has the email/user ID of the relevant users and simply isn't attaching that information, your proposal can call this out and recommend doing so. This proposal should be a well-written document.
    4. Run your proposal by the team - Set up a meeting, share the proposal in the invite, remind everyone to read it before the meeting, and use the meeting to reach a consensus.

    Ultimately, this entire situation is a big exercise in communication, so I highly recommend going through my Effective Communication Series if you haven't already.

  • Profile picture
    Robinhood, Meta, Course Hero, PayPal
    a year ago

    In terms of what a good bug report/task would have, I largely agree with what you put down but have some additional thoughts:

    • screen shots of current state and future state - If you're already getting a video, asking for screenshots on top of that seems like overkill. Also, I'm unsure how you would get the future ideal state screenshot unless the bug was already fixed?
    • video of current issue - Looks like you're already getting this, so this is great.
    • steps on how to reproduce - This is pretty standard, but if you're always getting a thorough video, this might not be necessary.
    • device information - I don't think it's fair for the bug filer (i.e. the everyday user) to provide this information: The onus is on the company to figure this out. You should be logging this automatically somewhere, so you can get this information after you figure out which users were afflicted with the bug.
    • potential solutions - This is something that you, as the engineer, would come up with after getting the initial bug report.

    Something that's missing from your list is some way to identify the user who filed the issue. This will be their user ID, email, or name in your product (you will almost certainly have the first 2 at least).

    In general, as the software engineer, you should be empowered to automate this as much as possible. Let's say a user hits some bug using your app/website and emails your company's support team letting them know. It would be annoying to ask that user for further information like what browser/phone they were using and what version of the app they were on. This is information you have access to within your product code - You just need to log it.