Index of Articles

taigeair

Exploring the world. Product manager at tech company. Mapmaker at Wellingtons Travel Co.

Ads via Google

Recent blog posts

    Product Manager Guideline: How to write a JIRA Ticket

    Product management is something you learn on the job, not at school or online, but this means there's a lack of educational resources out there. When I was leading the product department at a Berlin startup, I created a guideline on how to write stories on JIRA for the team. I've re-created one to be shared publicly.

    JIRA ticket

    First, you need to know what type of ticket to make and the relationship structure.

    • Hierarchy

    • Epic is a group of related stories and bugs related to a major business goal.

    • Stories describe a feature or a task and can be comprised of subtasks.

    • Bugs describe something that doesn't work as expected and how it should be.

    • Subtasks are usually written by developers to better organise and define their work; cannot be released by itself but only as part of a story or bug.

    We're going to focus on a story which is a feature to be developed. The parts of a story will be described from top to bottom.

    Important messages

    • If there is an important deadline or message to the developer such as a special procedure for implementation or deployment, I'd include it on top in red.

    User story

    • This is generally the first line of the ticket. It explains in everyday language what the user wants to do and why. It will include who, what's the goal, and what can help accomplish the goal.

    • Here's the template:

      As a <role>, I want to <goal/desire> so that <benefit>.

    • Here's an example:

      As a travelling business man, I want to see an trip duration estimation so that I can make an informed booking decision.
       
      As a cleaner, I want to see customer ratings for each job I perform so that I know if I did a good job or not.

    Priority

    • How important is this ticket? Usually it goes from low to high, but the exact wording is determined by each company.

    Status Quo

    • Developers who haven't worked on this before would like to know what has been done, what exists, and the general situation. Explain it here.

    Requirement

    • What needs to be built? Here's an example:

    • reschedule feature to let the customer change the start time and date of the appointment.

    Specifications

    • How should it look and behave? Sometimes it could be beneficial to separate those two.

    • Design:
      Specify what should be shown where. Here you can also include mockups or prototypes. Attach any graphic assets to the ticket and include hex codes, sizes, etc. Often the graphic designer can help with this. Responsive design should also usually be mentioned here.

    • Behaviour:
      Specify how the elements should behave. For complicated features, you should include a flow chart.

    • Integration:
      Sometimes developers need to have special access or work with other, so include credentials and contacts.

    • Tracking:
      Mention anything that should be tracked.

    • Multilingual support:
      Add multilingual considerations here.

    • Notes:
      Although it's not necessarily part of the specifications, it's good to be clear, so I usually explain possible any points of confusion here.

    • Questions:
      As I'm writing the ticket, I'll have questions so I just list them here until I have a chance to speak to someone who can answer them.

    Business value

    • Often companies would like to keep track of the ROI or business value of a feature so that it can be used during backlog prioritisation and sprint planning meetings. You can talk about revenue gains, cost savings, engagement, customer satisfaction, and other benefits here.

    Metrics

    • It's good to indicate which metrics we are measuring in relation to this story. For example, how many users are affected by this and what's the current engagement? This gives an overview of the scale of the feature and a snapshot of the situation before the feature is released.

    Estimations

    • Here the developers will estimate the story in terms of man hours or story points.

    People

    • Stakeholder: a person outside of product and development who has an interest in this ticket.
    • Reporter: the person who initially created the ticket, likely to be you; the product manager.
    • Assignee: the person working on the ticket, usually a developer or a QA specialist.

    Use cases or Test cases

    • You can write each use case in this section. Usually it's quite easy if you just go through the flow chart and enumerate them.

    • Example:

      Reschedules a cleaning with a perferred cleaner, more than 24 hour in advance
      Reschedules a cleaning without a perferred cleaner, more than 24 hour in advance
      Reschedules a cleaning within 24 hours of appointment

    • Test cases are similar to use cases but more detailed and used by QA to test the feature. It's written in a a special format that uses the 3 keywords:

    • Given - Given lines describe what pre-condition should exist.
      When - When lines describe the actions you take.
      Then - Then lines describe the result

    • Example (from TutsPlus):

    • Given I am on the home page
      And I am signed in
      Then I should see "Welcome Back!"
      And I should see "Settings"

    Acceptance Criteria

    • Here, you'd list anything that you require before the ticket can be approved by QA. Unlike requirements, these are measurable tests and checks that need to be passed to prove it's been correctly built.

    That's it. If it's helpful, I'll write more articles like this.

    Travel Sites For Finding Your Next Flight

    Flight Search

    This is a handy list of travel sites and apps I like. I wrote this post as a quick reference for myself and for sharing with friends when they ask me about travel sites. Feel free to bookmark it and comment if you know of other great sites.


    Get ideas for traveling.

    Hitlist - see where your friends have been and want to go.

    Kakay Explore - see places to travel to with estimated prices on a map.

    ZapTravel - get travel inspiration (see my review).

    Drungli - see places to travel to with estimated prices on a map.


    Know when to book a flight.

    Hopper - get airfare predictions and advice on when to book.

    Flyr - lock in airfare without committing to buy.


    Search for traditional flights.

    Kayak - vast selection of flights.

    Skyscanner - vast selection of flights.

    Hipmunk - great user interface for flight search.

    Google Flights - great user interface for flight search.

    Cheapoair - good prices.

    JetRadar - great selection and user interface on mobile app. I like it but haven't booked anything on it yet.

    DO NOT USE Opodo because their confirmed bookings sometimes fail and you will be stranded. See: Opodo Review: Worst Online Travel Agency Ever


    Search budget airlines.

    Skypicker - find cheap flights from budget airlines.

    Whichairline - search low cost airlines.


    Save money on travel by being flexible.

    Skiplagged - get to your final destination cheaper by skipping the final leg.

    Tripdelta - check for detours and get suggetions for alternative routes or times.


    Fly anywhere.

    "If the price is good and I’m free, I’ll go. I don’t even really care where" - if this sounds like you, read about secret flights. For example, Adioso.


    Find travel deals.

    Urlaubspiraten - see travel deals for Germany.

    Secret Flying - see travel deals.


    Search for ground transport

    CheckMyBus - checks trains, buses, and even rideshares such as BlaBlaCar.

    Kayak Cars - great car rental search.


    Lastly, I want to highlight a new startup TripRebel for hotel search. Book through it and if the price drops, you will get the lower price! For accommodations, I also frequently use Wimdu, Airbnb, Booking, and Hostelbookers.

    Have a great summer!