Author Archives: Artanto Ishaam

Scrum Jabodetabek Meetup – Chapter CiKemPon

Dear #scrum enthusiast around Cilandak – Kemang – Pondok Indah – etc,

Let’s join our 1st meetup. This is a community driven meetup, from us, for us, and pure sharing knowledge. For the 1st meetup, Kudo will become our host and sharing will be initiated by Joshua Partogi & M. Ichsan Rahardianto. Next meetup? it can be you (as a speaker), or your office (as a host). You also can bring your own food to share (potluck), etc. For being transparent, we also can vote who will become the next host during the meetup.

Let’s share our knowledge.

Just from us, to us.

RSVP: https://lnkd.in/fmx9mby

Multiple Team and Multiple Project/Product in JIRA

Yesterday, i read a beautiful article from Healthy Team Backlogs.

It’s all about how to make, organize, and manage our product backlog in a beautiful way. Honestly, it’s really helpful. You can implement some practices there. Let’s read that article then experiment it to your team.

But there’s a question from  in his article that quite makes me interested:

Scrum most commonly uses the term product backlog. However, many product owners who are new to Scrum are confused by this term. Reasonable questions arise: Does this suggest that a team working on multiple products would have multiple backlogs? If so, how do we prioritize between them? Where do bugs get recorded? What happens if work needs to be done, but it isn’t associated with a product; do we create a placeholder?

In this article i’m trying to answer that question in a summary. And my answer is: by using JIRA, how?

  • First, let me explain 2 most important entity in JIRA: Project and Board.
    1. Project is group of several backlog that is grouped based on similarity (based on the author purpose).
    – Similarity is subjective. It can be based on team, theme, mission, KPI, etc.
    – Due to support this article purpose, i put project as a group of several backlog that has similarity: contribute to one product.

    Project not associated with board

    2. Board is place to visualize our project.

    Project that visualized by the board (DEMO board)

    – Relation between Project and Board is many to many (m-n), so: one project is able to connect with several boards, several project are able to connect with one board, etc. (i’ll explain about this later, let’s continue!).

  • Second, let’s create 2 different project that represent 2 different product.
    – In this example, i created DEMO-1 and DEMO-2, let’s assume DEMO-1 & DEMO-2 are different product that our (full) tech-product team working on.

    Example of project

  • Third, create several backlog for each project.
    – To make it more likely a real backlog, we can put an epic to represent every each product (represent by project) has prioritized epic.

    Project DEMO-1, please do the same to DEMO-2

Then, let’s answer ‘s question one by one..

  • Does this suggest that a team working on multiple products would have multiple backlogs?
    Yes, multiple product can be represented by multiple project in JIRA. In this example: DEMO-1 and DEMO-2.
  • How do we prioritize between them?
    By using filter on the board:
    – Let’s create 1 board that visualized our team board. In this example, i named the team as “DEMO”. So, i create “DEMO Team”.

    Create a board

    – Choose what’s project source of the board that we want to visualized. In this example, we choose “based on an existing project” since we already have the project (DEMO-1 & DEMO-2).

    Choose the source of the board

    – Put board name as DEMO Team (our team name) then put DEMO-1 & DEMO-2 as our combination of 2 project (product) that we want to visualized.

    Let’s name the board!

    Ta da! we’ll see board that contain both product backlog (from 2 different product) that we will be working on!

    Let’s prioritized!

    So, currently we’re able to prioritized between this combination of product backlog.

    Then, how to differentiate between which one is backlog from DEMO-1 and DEMO-2?
    – Actually each project has a key that you can setup when you created a new project. In this example, i put “DEMO1” as a key for backlog from DEMO-1 and “DEMO2” as a key for backlog from DEMO-2.

    Setup a key for every project

    DEMO1 & DEMO2

  • Where do bugs get recorded?
    Before answer this question, i assume when the bugs is coming we easily to define the bug is coming from which product. So, for example the bug is coming from product DEMO-1. Then, yeah we just create a new bug that tight to DEMO-1 project.

    Create [BUG] DEMO G

    Board will also showing combination of each product (project) bug on the backlog, similar with the other backlog. Then, we are also able to set the bug priority and prioritize it along with the other backlog.

    Let’s prioritize the bug!

Finished!

Hope this article will help you to setup your JIRA for your team. I’ll share how HappyFresh tech-product team process in bug handling in the different article.

Here’s Atlassian documentation if you want to learn more.

See you!

Envy

Not this Sane

Scrum Master is the most sane people in the organization

I forgot where i got above quotes but it quite makes me envy and touch me a lil bit.

There will be a lot of uncertainty things happen during the day of sprint. There will be a lot of problem arise caused by the uncertainty things that coming. Some of you sometimes would be anxious, (fr)agile, un-stable, etc. And you don’t know how to retain your mentality, rise up when a big things hit you, etc. Not only about works, it’s also about your personal issue.

Please don’t worry, you still have your Scrum Master.

Hey, not all problem are appropriate to share to your co-workers

I know, but Scrum Master will treat you as their friends or even their family member. Scrum Master will put their problem aside, park it, and re-thinking about it later, then put your problem as their top priority. When you think it’s appropriate, don’t shy, just share it to them. Scrum Master will tell you the truth, the honest side one, even it gonna hurts you, a lot. Sometimes what we need isn’t what we want, it is?.

The envy part is:
When Scrum Master is arrived to become a servant leader, then serve you, help to solve your problem, who will help them to solve their problem?. Scrum Master is also a human, isn’t it?. Sometimes they also have a problem to solve, even their personal issue.

But that’s not your problem, don’t worry, we can take the rest of it. :)

So, please love your Scrum Master. For us, there won’t be any happier thing other than that.

Fasilkom UI Agile Coaching Session

With the lecturer

A great news comes from my college (Faculty of Computer Science, Universitas Indonesia): one of their courses, software project developent (PPL), will using agile rather than old methodology (Waterfall).

Wohoo!

It’s such a great news, since i realized, when join in industry, especially in startup ecosystem, we mostly using agile process. Why? because we usually work with uncertainty problem that sometimes easier to be handled using empirical approach rather than planned upfront approach. And agile process usually missed or didn’t get enough attention inside the courses. I remember it only contained in software engineering course, mostly theory, without any practical lesson. So, me (during that time) should learn from external resources :(. But that’s okay, as a student, there’s no boundaries to learn since there’s an internet isn’t it?.

So, a week ago, Rizky (also a founder of Agile Campus) tell me that Pak Ade Azurat (PPL lecturer) needs help to coach his students. This coaching session has a purpose to make sure all students have basic understanding of agile before they jump into the practical development. Of course it will be YES for me for the invitation!.

Then, here it is:

This coaching session basically only covered basic Scrum, included all inside Scrum guide and a little bit best practices (see some my experiment in Scrum and agile process here). Below are some best practice we share:

How to define a MVP:

How to make an estimation in agile development process using planning poker:

How to do a task planning

Thank you so much Pak Ade, Kak Maya, Pak Adin, & Rizky for the opportunity. It’s an honor to share and also learn from you guys and all Fasilkom students.

Thank you for making one of my bucket list checked: become a guest lecturer.

It’s a wrap!

Improvement Visibility

In HappyFresh tech-product team, another sprint means another experiment.

One of requirement from agile organization is improvement. Your organization should improving every hour, every day, every time. Improving means increasing positive things or removing negative things. How to be able discover that? usually some of agile organization do kinda sharing session between the employee and decide some improvement. But unfortunately the improvement sometimes comes with “top-down” approach, from top organization managerial, not comes from employees.

I’m grateful to have colleague & manager who value an improvement as a shared responsibility.

In Scrum framework there’s a session to accommodate that necessity, it’s called sprint retrospective. For those who don’t know retrospective session please read guides from Scrum.org here: Scrum guides. This is the example how we hold a retrospective session: Retrospective: Apresiasi dan Mesin Waktu.

Let’s jump into the problem and experiment.

Problem: Sometimes the improvement/action items from retrospective session still not “checked” by PIC (person in charge) of the action items by the end of the sprint.

Pre-condition: I usually use Confluence to documenting all action items, improvement, anything from retrospective session.

Question:

  1. Are they forgot to did the task/action items?
  2. Are they just forgot to check the items on Confluence?
  3. Are they just haven’t read the Confluence?
  4. Are they??

Hypothesis/Expected Result: If i make it more visible, it will raise the possibility of the items will be “checked” by them. “Checked” means they did the action items to avoid previous sprint mistakes.

So, what i did in previous sprint:

  1. I still used post-it in the retrospective session.
  2. But, rather than using Confluence to documented the problem and the action items, i used offline materials.
  3. I used A2 paper to put all post-it (contain with issue and problem).

    Avengers Retrospective

  4. I put that offline retrospective documentation close to team’s table, to make sure it’s visible by the team.

    Put it close to your team’s table

  5. The other advantage of this approach is, team also able to reviewed it in/after/before every daily scrum session.
  6. It’s kinda give them indirect pressure to avoid similar issue/mistake by did the action items.
  7. Additional tips: we also able to use offline retrospective documentation from previous sprint as a benchmark for the next sprint retrospective session, just to make sure the mistakes isn’t repeated.

And here’s the Result:

It’s all CHECKED.

Seems like make it visible will increase the awareness of the issue that lead to improvement. It’s not about something that should be pushed, it’s all about shared responsibility. Showing a commitment to improve shouldn’t because of reward and punishment from the organization.

What i want to also highlight: result isn’t the most important one from this approach, instead of learning process itself. So, i think it’s okay to not got all the action items checked by the end of the sprint as long the team has realized that they shouldn’t repeat any mistake in the future. Not repeating 1 or 2 mistake from 5 mistake is still improvement isn’t it?.

So, let’s help them to improve!