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 Chris Gagné 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.
2. Board is place to visualize our project.
– 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.
- 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.
Then, let’s answer Chris Gagné‘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”.
– 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).
– 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.
Ta da! we’ll see board that contain both product backlog (from 2 different product) that we will be working on!
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.
- 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. 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.
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.
For those who has registered, see you tomorrow!
I’ll facilitate open space session and available at coach corners. See complete schedule here: http://scrumdaybandung.com.
(unfortunately all tickets has sold out)
Intro to Scrum Day Bandung 2017:
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.
- Are they forgot to did the task/action items?
- Are they just forgot to check the items on Confluence?
- Are they just haven’t read the Confluence?
- 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:
- I still used post-it in the retrospective session.
- But, rather than using Confluence to documented the problem and the action items, i used offline materials.
- I used A2 paper to put all post-it (contain with issue and problem).
- I put that offline retrospective documentation close to team’s table, to make sure it’s visible by the team.
- The other advantage of this approach is, team also able to reviewed it in/after/before every daily scrum session.
- It’s kinda give them indirect pressure to avoid similar issue/mistake by did the action items.
- 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!
Just did a little experiment again.
Goal: To make team more aware with all of our definition
Preferrable outcome: More quality, less bug, less missed, and easier communication and coordination
We used to put all of our definition on Confluence. But it turns probably less people who remember all of this things, even less people read the page. I believe some of them have made all of this definition as their standard but as part of coaching, you need to make sure all of them have at least similar standard. Because agile development goal is high quality product, so we don’t have any excuses to reduce that due to time, scope, and any other parameters.
Do you think it will increase the awareness? maybe.
Do you think it will increase our product quality? probably.
At least we try, and learn from it later.
Tips on how to create definition (of done, etc):
1. Use clear parameter
2. Every items should be easy to define whether it’s passed or not
3. Make sure every member of scrum teams is involved during the definition process
4. Okay to put high standard, but also okay to build it iteratively
5. Let it rolling!
Will share the result on the next article (later)
“Beberapa dari kita hanya ingat akan ketidakpuasan, sehingga lupa akan apa yang telah rekan kita kontribusikan”
Sprint lalu saya mencoba modifikasi Sprint Retrospective yang biasa dilakukan oleh tim.
Biasanya kami menggunakan metode Mad-Sad-Glad (akan ditulis pada artikel lainnya), namun kali ini saya ubah sedikit agar sedikit cocok (atau dicocok-cocok-in) dengan tema akhir tahun. Metode kali ini saya coba namakan Apresiasi dan Mesin Waktu.
Alat dan bahan:
1. Post it 2 warna, usahakan gunakan warna cerah
2. Spidol secukupnya
- Post it warna pertama, tim harus tulis ungkapkan rasa terima kasih atas bantuan, pekerjaan, atau apapun yang telah dilakukan rekan satu tim-nya. Susah tapi harus dipaksa. Mengapa? karena tim harus dilatih agar bisa menunjukkan respect dan empati terhadap satu tim-nya. (Tips: satu post-it hanya boleh berisi satu poin. Jangan tulis poin yang berbeda untuk beberapa orang dalam satu post it. Alasannya akan dijelaskan di bawah)
- Post it warna kedua, tim harus bisa menjawab pertanyaan: “Seandainya kamu diberikan kesempatan untuk kembali ke beberapa hari saat sprint baru dimulai, apa yang ingin kamu perbaiki?”.
- Biarkan tim berfikir dan berdiskusi sambil menulis, namun tetap harus dalam koridor dua poin di atas.
- Tim satu-persatu ungkapkan poin pertama (apresiasi) dengan lantang sambil memberikan post-it tersebut kepada rekan yang sedang mereka apresiasi. Rangsang anggota tim yang diberikan apresiasi untuk dapat memberikan respon balik terhadap rekan yang sedang mengapresiasi (contoh: “Terima kasih juga ya”). Lakukan satu per-satu sampai seluruh anggota tim mendapat giliran.
- Tim satu-persatu ungkapkan poin kedua (mesin waktu). Lakukan satu per-satu sampai seluruh anggota tim mendapat giliran.
- Dari poin kedua, biasanya akan keluar berbagai macam hal yang ingin diperbaiki – ini merupakan cara lain untuk merangsang tim mengungkapkan permasalahan yang terjadi selama sprint.
- Contoh poin kedua (mesin waktu) yang berhasil ditangkap pada Sprint Retrospective lalu:
- Dari permasalahan-permasalahan tersebut, ajak tim diskusi untuk menemukan akar permasalahan/root cause. Karena belum tentu solusi yang diberikan masing-masing orang merupakan solusi yang objektif dan efektif untuk menyelesaikan akar permasalahan yang ada.
- Seperti Sprint Retrospective lainnya, akhir sesi ditutup dengan menuliskan seluruh action items yang telah masing-masing pribadi sepakat untuk lakukan berdasarkan proses hacking yang sudah dilakukan sebelumnya.
- Cek masing-masing action items, encourage tim agar bisa melakukan action items yang telah di-commit agar permasalahan yang sama tidak terjadi di Sprint berikutnya.
Atau kamu tertarik untuk merasakannya langsung?. Yuk gabung bersama kita di https://www.happyfresh.com/careers/jobs/tech-product/. Proses kita memang belum sempurna tapi kita berkomitmen untuk terus improve agile process yang kita miliki.
NB: Jika berkenan, setelah mencoba mohon tuliskan di kolom komentar ya bagaimana hasilnya, plus apa yang tim teman-teman rasakan.