Kanban is an approach that is one that focuses on trying to identify work in progress (and minimize it). Thats the core concept in it. It is based on the just in time workflows of Japanese car companies. Stuff that is stuck somewhere isn't moving as fast as it could through the workflow. Often it is paired with scrum in which case its known as scrumban though this doesn't have much to do with the agile principles.
For kanban to work well, the stories or tasks should be similar sized. Having a minivan go through the process that is designed to build scooter sized things will cause problems on an assembly line. So to it will have problems trying to push a task that takes a month through a workflow that wants to be pushing through tasks that are a week long. It can be done, but you're going to need to realize what it implies to the rest of the workflow.
Stories or tasks can have dependencies. Just one needs to make sure that the dependency is complete before the next one moves forward. Consider the situation where you have two tasks,
A must be done before
B can be coded. If you have both of these tasks in the backlog at the same time, someone might take
B first - this would be bad as it would have a task that is some state that cannot be moved forward - work in progress. Furthermore, if
A is started and is partly done then
B is started you can again have the situation where there is work in progress that cannot move forward.
That is why there is an emphasis on independent tasks. However, that does not mean that all tasks must be independent - just that you shouldn't have two dependent tasks being worked on simultaneously or in the wrong order. The control for this is the ability to put things in the backlog.
With attention paid to similar sized stories moving through the process and limiting how much can be in a given column at one time it is then possible to give better feedback to the customer about how long it will take for something to go through the workflow.
Thus, you may absolutely break it down into implementation stories or tasks. If you are using a physical kanban board, consider using a particular color sticky note for a partial detail of a larger story so that these can be seen and understood (possibly including the dependency information on them) so that they can be seen and followed more quickly when trying to get the big picture of the board.
There is nothing in kanban that has a parallel with the oft seen applications of agile that attempt to minimize design time (note, there's nothing in the principles behind the Agile Manifesto that suggests no design either though it may be a reaction to the "Welcome changing requirements, even late in development" or "Working software is the primary measure of progress" being interpreted as "design is worthless" - but I doubt any of the signatories of the Manifesto would make that claim). When one looks at various demos of kanban boards one sees things like:
That first image has a 'specify' column. The second one shows an 'Analysis' and 'Design' column.
As described in the principles behind the Agile Manifesto the key thing is to have working software and work with the customer. The individual responsible for putting tasks into the backlog is perfectly capable of putting internal refactoring tasks in there. I've also heard of managers doing entire scrum style sprints that are 80% internal tasks when necessary, or have a Friday refactoring day where you work on code cleanup on Fridays. The wise manager/product owner will do this because without addressing the internal (non-enduser facing tasks) the size of the tasks that can go through become smaller and smaller (and estimations for similar sized things become bigger and bigger over time) as increased technical debt is accumulated on the product.
There is nothing in agile or kanban that says you cannot have tasks of the nature 'refactor library XYZ'. If the product owner approves of the task to go through (or however the workflow for putting things in the backlog is) then do it. As mentioned, if you don't do it, development will eventually grind to a halt.
I will point out that not doing this goes against the principles: "Continuous attention to technical excellence and good design enhances agility." By keeping the code base in a constant state of a given quality one can do a better job at predicting how long the entire project will take (rather than having the velocity get slower as things get harder because of the technical debt).
In theory agile processes are supposed to be constantly refactoring the code, though this isn't something I've often seen. In part it has to do with how empowered the programmers are to say "this is how long something will take". In the situation of consultants working on a project, there is often a fair bit of "this will take as long as I say it will take," and take into account the constant refactoring. Such a statement is harder to do with in-house development where its a "it will take a week" ➔ "can you get it done in 3 days if you cut corners/don't do that refactoring thing?" ➔ "well, yea..." ➔ "great! 3 days it is." This is not so much a problem with agile, but rather the empowerment of the developer in the organization.
- What is Scrumban?
- Lean Software Scrum-ban
- Lean Software Kanban bootstrap I will point out that this post is specifically addressing the very large project issue that deals with breaking down large stories into smaller ones.