Hot answers tagged

11

TL;DR If the work matters, make it visible. If it doesn't, then treat it as muda and trim it as non-essential waste. You truly cannot have it both ways. No Invisible Work, Ever!™️ CodeGnome's Law of Transparency says "No invisible work, ever!" Any work that is off the books violates that law, as well as generally-accepted agile principles and practices. ...


11

You can have a technical leader. You can have him do work off the charts. You can hide this work from others that don't "need to know". You can reduce that person's capacity to make planning more accurate. But you cannot call that Scrum. One of the key features of agile (and, by extension, Scrum) is transparency. Transparency: This means presenting the ...


8

In JIRA boards are simply views on projects. It is the projects that contain the stories, epics and other issue types. This means that you can create a new board that points at an existing project. Say for example your original Kanban board was called 'Team X'. When that was created it would have created a project called 'Team X' as well. The board would ...


5

You can use swimlanes or Quick Filters to separate those views for your POs. Using Quick Filters: On your board page: Go to Board->Configure Select "Quick Filters" Add a new Quick Filter with Query "Issuetype=Story" On your board it will look like below: Using Swimlanes: For swimlanes the query looks exactly the same. Go to Board->Configure ...


5

Scrum doesn't say much about what a task board should look like, so most best practices are taken from Kanban. Some of the Kanban practices that seem applicable to your question are: The board should represent your team's workflow so that moving work through it creates a visualization of how the team is working. This creates opportunities to see bottlenecks ...


4

If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that. First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so ...


3

Ar some level it depends on what you're using the story board for. If it's for tracking what the team is doing, then you're right; this is overcrowding the board for no useful reason. But if you're using it as an overview of the project status then these dots are useful. Keep in mind that different people may be using this for different reasons, in which ...


2

From the Scrum Guide: Scrum is a framework for developing, delivering, and sustaining complex products. Everything in Scrum is centered around the development, delivery, and maintenance of complex products. In this particular case, the keyword there is "product". Everything in Scrum is also centered around three roles - Product Owner, Scrum Master, ...


1

It sounds like you are having a PBI/user story go through this sequence of states, and that's probably why they're proliferating. My teams have two states for PBIs (that are in a sprint backlog): Committed and Done. Each of those PBIs has tasks (e.g. design the UI, develop the front-end, test) that will get the PBI to its definition of done. Each of these ...


Only top voted, non community-wiki answers of a minimum length are eligible