New answers tagged kanban
4
To contribute and also help move the discussion forward, let's first start with the definition of WIP:
WIP is the number of task items that a team is currently working on.
When rolling out a new workflow, you monitor the average number of task items in each iteration and determine the WIP limits. However, it is not possible to know if the WIP limit is ...
1
Jira offers a series of very useful reports for different purposes. Reports in Cloud and Server instances of Jira are mainly the same, as far as I could see.
For Jira Kanban specifically, there are two specific reports (details obtained from the source links):
Cumulative Flow Diagram:
A Cumulative Flow Diagram (CFD) is an area chart that shows the various ...
2
TL;DR
I'm not going to address your math directly, because it's a solution for Y in an X/Y problem. Specifically, how long it takes to complete your current backlog should be a function of your current lead and cycle times, not an invitation to resize your queues or attempt to crash the project by adding additional resources.
What you really ought to do is ...
2
In Kanban, we want to visualize whatever the workflow is, so if that is your workflow, that is what you should represent.
That said, there is another part of this answer. Kanban asks us to manage the work, not the people. Therefore, in your example, you would usually represent this work the same way regardless of if it is your team or another.
6
TL;DR
Hold the event daily, even if you don't use the whole time box allocated for the meeting. Don't skip it routinely, even if you think you have good reasons. Doing so may not bite you right away, but it probably will eventually.
If you're not finding value in the Daily Scrum, it's likely because the team isn't really performing just-in-time (JIT) ...
13
One of the advantages of having such a small team is that, indeed, the people in the team are able to communicate freely throughout the day. A lot of the daily stand-ups might thus often end very quickly and may look like they are a waste, but they can still have a purpose even in a small team like this: to provide extra focus.
The daily standup allows ...
0
In Agile it can be useful to think of individuals having a capability rather than a role.
Jill has a capability to do development work
Sam has a capability to do testing work
Helen has a capability to do both development and testing work
If our team is full of specialists who can only do one thing, then when we bring work into a sprint it can ...
2
The Scrum Guide states a few things about the Development Team - it is "self-organizing" and no one can tell "the Development Team how to turn Product Backlog into Increments of potentially releasable functionality", that there are "no titles for Development Team members, regardless of the work being performed by the person", there are "no sub-teams in the ...
0
Ask yourself the question - "How do we do this today?". Then map that process to your Kanban board.
Most software/ product teams have people who perform multiple functions - and they are expected to perform these possibly multiple times in a day or depending on how heavy their own workload is, at specific times during the day or week, or even longer - ...
0
It is certainly not an anti-pattern in Kanban. However, ideally, a card should show an "assignee" only when the card has been pulled from the Backlog or Ready column into an in-progress column.
Whether you have someone on your team "assigning work" to other team members (perhaps that is what you are referring to as an anti-pattern) or whether you have team ...
1
Kanban's first principle is "Start with what you do now." and iterate from there. So, what you want to visualize is completely up to you, based on what you do today to track data about your work items.
If you have absolutely no current process/ practice regarding something, start somewhere - take a decision as a team that "we will visualize these things ...
0
TL;DR
Code should be reviewed when someone is ready to review it, and when the team has the capacity to perform the code review without "stopping the line" or impacting other work-in-progress.
Analysis
In any pull-queue system, work is pulled (never pushed) when someone is ready to work on it. So, work should be pulled into your "Code Review" column when:
...
2
It depends.
It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work ...
0
There's more to Kanban than just using a board to visualize the work. It seems like you may be missing two key aspects - a pull system and work-in-progress limits.
The workflow that you describe seems mostly correct. I would add one additional state between CODE_REVIEW and TESTING - READY_FOR_TESTING. This would help implementing a pull system, where the ...
1
TL;DR
If you're going to do it at all, you might have people assign themselves to a work item to indicate who pulled it. No one should ever be assigning work to individuals other than themselves in any well-respected agile framework.
However, while generally an anti-pattern, taking the role of card handler/coordinator is certainly acceptable in a pull-...
3
Why would this be an anti-pattern? One of the Kanban principles is about visualizing the workflow. Being an Agile practices, it's also about transparency. Look at the board and you have an image of what's going on. That means what work is in progress and - if you have an assignee on the card - who is working on the items.
If you find it useful, you can add ...
2
TL;DR
While there can be circumstances where you need the level of granularity you're proposing, in most cases it's likely to be a symptom of command-and-control management styles and an outgrowth of the 100% utilization fallacy.
Kanban should generally be tracking significant state transitions at the product level, not attempting to prescribe procedures ...
1
A Kanban board needs to visualize at least two things.
The columns on the Kanban board visualize the states of work in the workflow. Through this, the workflow or process by which work gets done is visualized, allowing anyone to see how work gets from "not done" to "done". Along with this, most Kanban boards also capture information like work in progress ...
2
JIRA allows you to modify your workflow and add new statuses. You don't need to divide columns, just add new columns that reflect what you want.
I would look to build a workflow something like this:
To Do
Dev
Dev Done
Test
Done
Thus a tester would look at the "Dev Done" column for work that they can pull into "Test".
If you have ...
1
In Jira, the default columns on a Kanban board are Backlog, Selected for Development (To Do), In Progress, and Done.
For each column, depending on the workflow you're using, you have different status.
If your board's project is using the Jira default workflow:
To Do - Open, Reopened
In Progress - In Progress
Done - Resolved, Closed
You can change ...
1
Personally, I think you do need to spend time and decompose your tasks. Looking at your examples, if you don't decompose, you'll end up with tickets that remain in progress for much longer than you prefer.
As a good example, let's look at Subtask 2
Implement the search function
You have presented this as if it has already been decomposed from the ...
1
I would advise against a sub-task approach as it is often painful for Devs to have to update each sub-task with their progress.
Your first subtask sounds like it is more appropriate as a Spike.
Subtask 2-4 sound like they could be acceptance criteria in a single story
Subtask 5 could be a task item or a subtask (either on is fine)
A driving principle ...
3
TL;DR
In agile frameworks such as Kanban, you shouldn't have to care about how the work is allocated within a process state such as "development." That's up to the team. Just focus on right-sizing the WIP limits to ensure they are based on available team capacity and optimize for flow rather than individualized tasking.
Limit Work to Optimize Flow
From a ...
0
From the Agile Manifesto,
Individuals and interactions over processes and tools
It's hard to tell, with just a glance at the board, how many items are in a column, and why column WIP limits are important.
Comparatively, if you have someone who is unaware that s/he is working on multiple tasks, you have a much larger problem than this.
Likewise, it ...
1
It depends on what you are trying to visualise.
Kanban is about optimising a workflow and visualisation is an important part of this. If your sub-tasks represent stages of a workflow then it may make sense to represent them as columns.
If, however, your sub-tasks are very fine-grained then this could result in a Kanban board with a large number of columns....
2
Kanban is about visualising a workflow. It helps teams to synchronise their activities and to improve their process.
Your question comes down to how best to visualise your current setup.
Advantages of a single board:
A single view of all workflows
It may highlight contention for resources between projects / systems
Disadvantages:
Unrelated activities ...
1
There are lots of different approaches you can use for this.
For example, I worked with one team that used custom fields to show the individuals that were involved in a ticket (e.g. "Developer", "Tester"). They populated the custom fields using pop-ups during transitions. This saves people from having to trawl through the ticket history, but it can get a ...
3
Jira items have a history. When you move items from one column to another, that change is recorded and you have the history. You can find out who all the assignees were.
And to be honest, that goes for your people too. If you move one item from "development" to "code review" and you re-assign the Jira issue, you still know who developed the code, don't you?...
1
Due to the nature of most Agile development, the details of a given piece of functionality can change over time (in fact, if this isn't true, you aren't very agile). Therefor, what is on a given card in your backlog is just a description of that point in time, making it ill-suited for long-term documentation. Further, documenting too much in cards can lead ...
0
I have successfully kept the "issues" in Jira and then used Confluence for the type of documents that you are mentioning. My recommendation would be to keep your documents in a more appropriate system, for instance Confluence.
Sure any kind of documentation system would do. Both Jira and Confluence are from the same provider, Atlassian.
Harry
Top 50 recent answers are included
