When it comes to Jira I’m not it’s fan. Recently I’ve struggling with very difficult SCRUM project related somehow to health industry. It was not very complex one, but deffinitly deadline was an issue here. We have working on second milestone, preparation to pilot release for big customer. First milestone was focusing on preparing proof of concept, by development of prototype version of the system. It’s worth to notice this detail.
First of all I’ve decided to preapre backlog with stories, but due to previous phase and lack of constant contact with customer, I’ve used UX design as an inspiration. Yes it was already there. I thought it would be great idea, but not. But lets stop here with, no spoilers. Backlog should always be prepared and prioritetized by product owner, it waits there till next Sprint planning happen. Thats it, waiting, sometimes it’s enough time to get obsolete, so do not get into details here. It should be cheap to replace or update. Ok, but when it should be updated?
I found preaty good setup here, let me introduce it by some example. There is 2 week sprint (classic), couple of components, some server, mobile application and let it be some wearable (yes, they not died). Now, you need some time to prepare backlog from the stacks of documentation and meeting notes, whatever you have got, obvious is to start Sprint 0, it could be shorter than usualy, but idealy should be same as other sprints. During this time you live with your teammates on short loop. Prepare your epics and choose some to form a Sprint 1 goal. It should be sliced across all components, so they would immidietly form an ‘Walking Skeleton’* of your system. However Sprint planning is task for team, so prepare some more detailed Stories which fits a goal. Remember to give your developers some move, freedom, so they could choose task which fits them best. Stories should be filled with enough of details so they could be broken down on subtasks which would be more technical. During one of retrospective we have decided to fill subtasks in other meetings so we would not spent too much time during Sprint planning. Hey! You should ask, thats not a good practice to plan tasks off the record of whole dev team. Yes I usually agree, but remember the setup, backend, android app, wearable, those components needs in most of the cases different speciallists, so 1/3 of people on the meeting was bored and frustrated. So since that retrospective we were obligated to fill component name in Jira story form. It become so handy in organizing Story brainstorming. After Sprint 1 has been in progress, you have some time to analyze more stories and prepare backlog before you start Sprint 2, and it goes in cycle. At some point your project would have full backlog filled. I use this session one on one with next Sprint plannig as an oportunity to remove all stories from there and update obsolete ones. This is called backlog grooming.
From this point I can say that now I much more satisifed with detailed stories always ready for sprint planning. Most of the backlog is hidden in epics and some stories wich description is not ready enough to be developed so they are quite cheap to modify or remove.
But I’ve hang a gun on the wall above the fireplace, someone should got be shoot in the foot, right? So what is the reason I’ve mentioned PoC, because in project with very demanding deadline it’s very tempting to use prototype code in further development. Bam! My foot is hurt, we are using prototyp implementation, so how to filter all stories which were already done? The answare is do not filter, forget about prototype, live it to developers to decide if prototype code is sufficent. Stories should be same as it would be new functionalities implemented from scratch. It would be verified by velocity if prototype was helpful or not, some stories would completed faster, other not, simple as that.
However I’m still strugling with some issues I going to list below:
- Stories granulation adjustment.
- Stories inspired by UX tends to be too detailed and too fragile.
- Jira epics are so strangly implemented, that I suppose I’m using them wrong.
- How to discipline planning story development by subtask
- Working with UX and UI using Stories is not ideal solution.
For this questions I would try to find answare in further short blog entries, as some sort of series. I belive that some or most of you already knows answares for that questions, for sure, I’m not first and last here, but road matters. Product Owner role is new to me, so I’ve started to writing down my findings so I can refine my favourite tricks ane could observe a progress I made. So if you like you can share with me your thought by the email in the footage.
Keep finges crossed so this post is not last one.