JIRA Story Board Help

As surely as you need a PO, you also need a product. Where are your products here? Is each “program” releasable in such a way that value can be measured for it? Why are you “winding down” the product focus you appear to have established?

Ian thanks for the reply. So we have 22 programs within the Accounts Payable package so we have 22 products that we are nearing the release to our customers. Throughout development of the Accounts Payable package, we have developed releasable products with each sprint that were sent to our internal stakeholders (upper management). They have decided to not release the products until all of them within the A/P package are complete. Once the package is released, the development moves to our next batch of products; we will maintain them as needed but the development focus moves to our next batch of products. That's what I meant by winding down. 

Ultimately it kinda comes back to if we had a JIRA board in developing Microsoft Office, would we have a board for Excel, another for Word, another for Powerpoint, etc; or would we have a single board for "Microsoft Office" that encompassed everything? 

Trust me, it is absolutely not ideal and truly not Scrum; but I'm really trying to get them on board so I'm forced to do a Scrum hybrid of sorts. I would love nothing else than to have them scrap what they did in the past and get a PO and go full Scrum but that is not going to happen until I can prove the value of Scrum. 

They are beginning to see the light but they will not be investing in the human capital necessary for the time being so I'll be doing multiple roles for the foreseeable future. Personally, I like it because it gives me some great experience and it's definitely a challenge; but I'd be lying if I said this is an ideal situation. 

Hope that makes sense.

Hi Curtis, I know that Jira can be configured in some many different ways to accommodate your teams and backlogs.

You described how the product is structured in general. What I'm interested in is how the teams are structured.

Do you have several teams working on the same set of products? Can they pick up any work from this set of products? Or are teams assigned to specific packages (say Team 1 only works on Word, Team 2 only works on Excel)? 

Hey Daria, thanks for the help. We have a single team that can pick up any work from the set of products. The team decides who will work on which product; so 1 member would be working on Excel and another working Word at the same time. 

I have 6 developers total, so we could split into 2 smaller teams but knowing the developers that I have; that wouldn't work as well. 

How do team members collaborate when developing products? The purpose of a board is to help the team achieve transparency over their joint plan of work.

Hi Curtis - What I have seen and created when multiple teams all work on the same Product Backlog and need to scale, but need their own Sprint Backlogs and associated boards and filtered views of the Product Backlog, is to use Jira components.  Components are easy to create in Jira.

So if you had the Word team and Excel team, you would create two components called Word and Excel, and two associated Jira Scrum boards.  Each board would use a Jira query to link to the components.  You would tag each Product Backlog item with a component, so that it is picked up by the filters and queries for appropriate display.

And you will probably want one JIra board to see all teams' Product Backlog Items, so would create a third board and write the query to include all components.  So you would have three boards.  A broader program level board, and two team level boards. 

Hope this helps.

Chris

Ultimately it kinda comes back to if we had a JIRA board in developing Microsoft Office, would we have a board for Excel, another for Word, another for Powerpoint, etc; or would we have a single board for "Microsoft Office" that encompassed everything? 

As I'm sure you know, the Scrum Guide refers to only one Product Backlog per product, and one Sprint Backlog per sprint. 

A board is usually an effective tool for making the Sprint Backlog more transparent, so I would ask you to challenge whether having multiple boards helps or hinders transparency. 

How about taking JIRA out of the equation altogether (at least for a Sprint or two); make a physical board (or boards) to make the Sprint Backlog visible, and see if that does the job? Once you have a good physical setup, you could then try to build that in JIRA if the development team see value in it.

If it's not easy to display the Sprint Backlog in a low-tech way, I would seriously question whether the development team are able to focus on what is in the Sprint Backlog, and inspect and adapt it effectively.

Trust me, it is absolutely not ideal and truly not Scrum; but I'm really trying to get them on board so I'm forced to do a Scrum hybrid of sorts. I would love nothing else than to have them scrap what they did in the past and get a PO and go full Scrum but that is not going to happen until I can prove the value of Scrum. 

Trying to find comfortable workarounds for things you consider "truly not Scrum" can reduce transparency. If people don't see what is going wrong, it is difficult for them to work empirically to make things better. In an organization that doesn't get the point of Scrum, implementing a changed version of Scrum makes it very difficult to compare Scrum (done properly) with the alternative(s).

I appreciate everyone's help on this. Let me take a step back and clear the field, so to speak. 

First, it would be helpful to define what a product is in my environment that I am in currently. Going back to the Microsoft example, is the product Microsoft Office or is the product Word, Excel, Powerpoint, etc? That is one of the biggest issues I need help with because our software is similar in that we have packages that consist of several programs that encompass the package; just like Word, Excel, and Powerpoint makeup the Microsoft Office Package. I have a single scrum team working on this. I've not been a PO so I haven't had to worry about setting up the backlogs before. I'm hoping to take the PSPO course in a few weeks as that will help tremendously but I don't know if my company will cover that course; so I may have to wait longer to take it.

Right now, my team cannot focus properly on the tasks at hand because of the way the JIRA board is setup; that is what I need help with. I need ideas of how you guys would setup your backlog boards if you were working on Microsoft Office with a single team, like the example above. 

Disclaimer: Jira is built in such a way, that even talking about how to use it makes me use some un-Scrum terminology. But here goes...

There are many ways to set up Jira, and I think without understanding how you are using it, we're going to get our wires crossed.

Where I work, we do something like this during Sprint Planning:

1. Look at the backlog for the Jira project
2. Click the Create sprint button
3. The Development Team drag the forecast items in to the sprint
4. Click the button to start the sprint (Start sprint, I think)
5. Enter the Sprint Goal
6. Set the sprint end time as when the Sprint Review is planned to begin, so that the burndown chart has a useful guide line.

That means we then have one board under Active sprints, and this displays everything the team has put in to the sprint.

Is that similar to what you do or have tried? If so, what are you/the team finding unmanageable?

If not, is there something in how you have Jira configured that doesn't allow this, or do you perhaps have a different way of visualizing a Sprint Backlog in Jira?

Could it be that Jira has been set up to suit other teams/stakeholders as well, and so it's placing extra constraints on how the team uses it?

Simon, Thanks for the reply.  The way the team currently uses JIRA doesn't matter because we are completely changing the game here. Be it JIRA or sticky notes on a wall; I still need to know whether we should have a board per program (Word, Excel, Powerpoint, etc) or a board for the package (Microsoft Office). I really appreciate the help but I know how Scrum works, right now I just need help on one piece; setting up the backlog. 

Forget JIRA, the tool used doesn't make a bit of difference; using the Microsoft Office example how do you setup the backlog? Does the Product Backlog cover everything in Microsoft Office, or should there be a product backlog for Excel, another for Word, another for Powerpoint? 

I apologize if this comes off as disrespectful, that is absolutely not my intent. I know I should have worded the original post differently and that may have helped steer this conversation more efficiently. 

I think you recognise that one of your problems is not having a clear definition of what products you have. Of course this is something you should try to address. At least try to keep problems transparent, so that there is a good case for resolving them.

But it seems at this moment that the team's de-facto product is "Microsoft Office". As far as I understand, they expect to be working on "Excel" and "Word" in the same sprint, and this all comes from the same Product Owner (you), who has prioritized the various product backlog items, with the goal of maximizing value to the "Microsoft Office" product.

Perhaps this is the order that you want things done:

• Add basic arithmetic formulas to Excel
• Add print preview to Word
• Add copy button to Word
• Add slide from the right effect in Power Point
• Add paste button to Word
• Add cut button to Word
• Add Comic Sans font to Excel
• Make slide effect also work from left in Power Point

Essentially this is your Product Backlog. During Sprint Planning (and at other times), the Development Team need to know what is at the top of the Product Backlog. So does it help the team or anyone else to have this split in to separate lists? 

By the end of Sprint Planning, the team should have a Sprint Backlog, and they need to be able to inspect and adapt this in order to meet the Sprint Goal.

If the Development Team have chosen the top five items, and they have (somehow) managed to craft a Sprint Goal with you that covers getting those items to Done, how does it make sense for them to visualise it?

I suggest by default, they should try to fit it all on one board.

If that doesn't work for them, it will hopefully become apparent quite quickly (perhaps it already has), and it should come up during the Sprint Retrospective.

At that point you might need to work with the team to find a solution.

It could be that the team need multiple boards; it could be that it makes sense to define "Word" as its own product and have the team responsible only for "Word"; it could be that you haven't developed a clear product vision, or that the vision doesn't relate to the Product Backlog; and it could be that the team need just a little bit of time or help to iron out small problems here and there.

Simon, thanks again for your continued help. We have a solid definition of the products we have but I'm always looking for a better and more efficient way of doing something. The majority of the issues I have where I am is the Product Owner aspect is very, very new to me. I'm well-learned in the roles and responsibilities of what I need to do as a Scrum Master but the Product Owner aspects are where I'm lacking; again I'm hoping to go through the PSPO course to help with that. It will be a long road and a huge amount of trial and error to get this off the ground here but it's also exciting to me. I look at it through the lens that I'll be able to use this experience in the future and it will come in handy.

Currently, the team uses JIRA by package (Microsoft Office style) so that aspect will be a smooth transition, but they only use for bug filing. The directive the developers had prior to me joining the team was to look at the old version of the program and update with certain improvements here and there and make it work across all browsers. Does your head hurt when you read that? Mine does too...

It's been a huge struggle because since there is no definition of done right, no product backlog, no vision, and no goal; it's like going on a road trip with no map and no determined destination but you have to reach that destination in 4 weeks. Our upper management just came in through the last month and ordered a complete re-write of a few of the major programs but they expect it to be done with no added time to the release date. 

Here is the great thing, when this is all said and done, I have a meeting scheduled with upper management to show them how utilizing Scrum will save all this headache. Having a defined backlog, broken down into sprints, incorporating them in the reviews throughout so we don't have a full re-write near the finish line, and all would greatly help this team and company. Maybe I'm a bit too optimistic but I'm also of the mentality that they can either give it a try or not, I can still utilize my skills here and there and if need be; look for a company that is on board with Scrum.

Anyway, thank you again for the help and insight!

Our upper management just came in through the last month and ordered a complete re-write of a few of the major programs but they expect it to be done with no added time to the release date. 

I love seeing this type of "old school" thinking, with little understanding or care around true capacity.   I actually enjoy pushing back on this type of thinking, asking why they believe additional scope can be completed within the same time period, and whether they have any available data or metrics to support their assertion that the work can get done.

I love seeing this type of "old school" thinking, with little understanding or care around true capacity.   I actually enjoy pushing back on this type of thinking, asking why they believe additional scope can be completed within the same time period, and whether they have any available data or metrics to support their assertion that the work can get done.

I do too, and in the future projects I will speak up a lot more. This current project has been much more a sit back and learn what they have always done and use it against them (so to speak) in the future projects. I know the upper management didn't like doing that but they did because they hadn't seen the products before. There is a huge lack of transparency here and I'm constantly debating with my architect about the benefits of transparency across the board. Most of my developers have been here for 5-10 years so they are used to developing something, testing it and getting it to a releasable state; only to have management come in and scrap everything and order a re-write. I know all of you are thinking "Man, more transparency and reviews with the stakeholders would resolve that issue real quick"; trust me I'm working on it.