Hot answers tagged

53

If at all possible, they don't. They ask developers to estimate it. Estimates should always be made by the people who will perform the work being estimated. If this is not done, then you run the following two risks: The estimate is inaccurate, as the person who estimated it did not have the knowledge of what work needed to be done The people who do the ...


42

Good question - well phrased. Best answer is "Never be the senior guy with a secret". Development is difficult to schedule. Last week I told my manager that the new tool enables me to solve very complex tasks in 5 minutes, but sometimes very simple tasks take a day or more. That experience is fairly common to most of the development tasks I've ...


21

A Kanban board helps developers synchronise their work. Sue glanced up at the Kanban board to see if there were any new items waiting for her to code. Mark had noticed that the review stage on the Kanban board had hit the work in progress limit and so decided his next task should be to review something. Karen had just heard that the deadline had changed and ...


18

Responsible vs. Accountable Roles in a Pull-Queue System The question you're asking is really an X/Y problem. You have a couple of other problems that you haven't actually called out in your question: Kanban is a pull-queue system, not a push system. So, unless the API team knows to pull from your "feedback" column, or unless they have their own backlog ...


17

Being new to Agile can be overwhelming with all of the different terminology that you hear getting thrown around. I had difficulty grappling with these two words in particular at first, as well. I'll try to lay out the major methodological differences, without getting into the philosophy, where I'm not quite so strong. Scrum: Teams work in sprints, ...


17

TL;DR Your question strongly implies management metrics tied to individual utilization rather than flow or cycle time. The 100% utilization fallacy is antithetical to Kanban, and to agile systems in general. Furthermore, Kanban systems aren't intrinsically concerned with how much time individuals allocate to a given task. Instead, they focus on the cycle ...


16

Depending on how often this happens, you could consider defining your Kanban board by 'class of service' - where you can use the Class of Services defined by David Anderson in his book: Kanban: Successful Evolutionary Change for your Technology Business. You might consider all of the classes of service - Standard (normal work), Expedited (customer or other ...


14

Most common metrics used along with Kanban are: Cycle time / production lead time There is some confusion over naming so let me explain in a bit more detail. Production lead time or cycle time is time that elapses from the moment a team starts actively working on a task till the moment they are done (or done-done). This metric basically say about how ...


13

I would focus on the need, rather than the implementation. The user story would then simply be: "As a user, I want any personal information I give (Company) to remain private and secure." With HTTPS then being an implementation detail of that story. After all, if you found some other means of completing the requirement (such as not getting any personal ...


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 ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


12

TL;DR Don't think "time tracking." Think "cycle time" instead. Kanban Should Measure Cycle Time Generally, Kanban is not about measuring "activities" at a granular level; it is about measuring cycle time for a pull through the entire system. There is legitimate debate about whether this time should include lead time (e.g. time ...


12

TL; DR In Scrum, a time-boxed daily stand-up with a structured format is mandated by the framework. If you don't have a daily stand-up, you aren't following the core Scrum methodology. Kanban is less prescriptive, and doesn't actually mandate the daily stand-up as a formal ceremony. However, Kanban teams often borrow the practice from Scrum for the same ...


12

TL;DR You are taking a potential team composition problem and making it your problem. That is not agile; that is a misunderstanding of your role. From an agile coaching perspective, teams need to be guided into assessing and resolving their own bottlenecks, whether it involves technical or human resource issues. Analysis I am at odds as I presume this ...


12

My answer is: there are no predefined artifacts in Kanban. Scrum has predefined roles, events, and artifacts but Kanban doesn't. Kanban just describes 4 principles and 5 practices: Start with existing process; Agree to pursue incremental, evolutionary change; Respect the current process, roles, responsibilities and titles; Encourage acts of leadership at ...


12

As a developer, a kanban board shows me two things of interest: What work am I and my team members currently working on What work is ready to be picked up when I complete my current task Besides that, it is nice to have a place to leave the work card to announce it has been completed. In a situation where there are no hand-overs (or significant waiting ...


12

The main ideas with Kanban is to visualize your work and to limit work in progress. This allows you to maximize flow while at the same time see where you have bottlenecks. If you started work on something that now needs to stop for whatever reason, you need to remove it from your work in progress. What you do with it depends on what exactly you want to ...


11

IMO, all four of the activities you cite are things that should be handled by a project manager and/or product manager. If you are currently performing this activities, then you are acting as project/product manager and lead developer. (Time to ask for a raise.) I would structure things a little differently rather than just adding kanban to the process (...


11

It looks like you have a problem in the ways stories are written. Stories represent an aim which has a value for an actor. If you think about the Mike Cohn version of user stories: "[The actor] wants to do [the aim] in order to get [the value]". If you can identify these three elements, the scope follows logically. The conversation that needs to ...


11

You can't compare Scrum and Kanban. Scrum is a project management framework, while Kanban is a scheduling system to support Lean and Just-In-Time operations. Kanban is one of the tools used in Lean. There is a form of Lean for software development called Lean Software Development, but even that can not be compared to Scrum. However, there is a relationship ...


11

Have Task Performers Provide Estimates In agile frameworks (and even in sensible non-agile frameworks), project managers should never estimate work items themselves. Instead, the people who will actually do the work ("task performers") do the estimation! To get the most realistic estimates, have the task performers estimate the time and complexity of the ...


11

I think this has a canonical answer, at least from a traditional PM point of view if not with Agile or Kanban or whatever else. If a piece of work was unable to be finished for whatever reason, by the mechanic, developer, trades person, whomever, then the issue falls back to the PM or PM control part of the project to be tracked and resolved. The ...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


10

My opinion is that you have a very good approach at hand by creating separate swim lane for bugs/issues on the same wall/board. Visibility is the main reason why I am inclined towards this approach. Having two separate systems to manage your to-do list is not going to give you a complete picture of the current status. Visualizing the flow of work and ...


10

Kanban certifications are definitely not as well established as Scrum training/ certifications. But they certainly are available. The Lean Kanban University, with active involvement of/ direction by 'Kanban Method for Software' pioneer David J Anderson, has been issuing 2 kinds of certifications - AKT - Accredited Kanban Trainer - and KCP - Kanban Coaching ...


10

Wiki has the common definition of this term: A lead time is the latency between the initiation and execution of a process. If your working area is software development, then the definition from JIRA golossary may be more understandable for you: Lead time is the time taken from when an issue is logged until work is completed on that issue. In ...


10

TL;DR What are the pillars of Kanban process? Are they the same [as Scrum] or is something different? Kanban doesn't define "pillars" in the same sense as Scrum. However, as one of the core agile methodologies, it espouses a set of rules and principles that do map to the same agile objectives. The current set of six practices (described below) ...


10

Lean is to Kanban as agile is to Scrum. One is a concrete implementation of the other. Using the term "lean kanban" is just an attempt to court favour from Google/Bing for keyword density and is the result of copywriters rather than an actual thing. All Kanban is Lean... But not all Lean is Kanban...


10

Having more than 1 item In Progress for a single person will kill productivity. Multitasking is horrible for getting things done quickly and/or well. See Agile team full of part time developers for more details. It might seem like a good idea to pull in new work if something gets roadblocked, however this is, in essence, optimizing for utilization (making ...


10

In a word: feedback. Whether you’re coaching a soccer team, flying a drone, planning a city, or writing a dissertation, the sooner you can get feedback, make adjustments, and get more feedback, the more successful you’ll be. In Kanban, you get feedback by completing stories and observing how they affect the system. A smaller story can be done faster, ...


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