How to handle story points that run over sprints

[Jason Ried]

Recently we setup multiple Kanban boards to help with our agile project however we have realised that we will always have stories that run over our sprint periods of 2 weeks. I was hoping someone had examples of how to handle this or how we can better handle this.

Our setup is as follows:

• Agile board for the project and this essentially tracks the status of stories with: To Do, In Progress, Done & Closed
• Kanban board for artists which has: To Do, Concept, Model, Texture, Rig, Animate, Review, Approved. Once things are approved it moves to Done in the Agile board.

We have other boards but for the purpose of this question the below is enough detail I believe.

Then we have stories which for example are "Character #1" and we estimate a total time to complete this of say 13 days. We use points but over time we have realised our perception of hours and points are very similar.

The main thing to note is that the 13 days is made up of say: 1 day concept, 3 days model, 3 days texture, 2 days rig, 4 days animate.

If we now have the single story Character #1 then when we add it into the sprint (which is 2 weeks) then this will run over. Obviously this is against the concept of agile.

Prior to setting up the kanban boards we would rather have an Epic of Character #1, which had stories for concept, model, texture, rig, animate and each had their days. This was a lot easier to plan a sprint as it means we could correctly allocate the right amount of work. The downside was that we didn't follow a clear path through a    workflow as per the kanban boards.

Does anyone have any good workflows/suggestions that would work well in this instance? 

[Nic Brough -Adaptavist-]

Kanban does not have sprints, so it's unclear what you're actually trying to do with these boards

If you're using them as views of a Scrum type process, which does do sprints, and you've got a Scrum board covering it, then that's fine, but you don't need to worry about the numbers moving on the Kanban boards - that's not what they're for.

>we have realised our perception of hours and points are very similar

They shouldn't be - points and time are totally different measures.  If you do find you're thinking mostly in time, then dump the story points and embrace estimates properly.

[Jason Ried]

Agreed on the story point / hours - we will revise this later on.

For the kanban boards we are using them as views of the scrum process. I think the problem with numbers not moving is still relevant to the scrum board though, since we are creating Character #1 and it is more points than allowed in a sprint. It has more points as each aspect (as shown on kanban) totals up to more time than available.

Is there a better way to do this then? How else would we assign Character #1 to work, see it through the kanban board, but importantly also stick to our sprints?

Our previous way was to break up Character #1 as an Epic which has lots of stories, but this then doesn't work nicely on kanban boards.

[Nic Brough -Adaptavist-]

I think you're over-thinking the kanban boards - they really are just simplified views of what is occurring in a more planned and structured scrum that's going on behind them.

You are right about your problem with numbers being too big for a sprint, it's a common thing to happen in Agile.  The answer is still covered by scrum methodology though, and you've been doing the right thing.  Split the story into more manageable chunks so that it can be tackled in several sprints.  Some places will do a simple split and link the new story to the old, but it's also common to convert the story into an Epic and then create new stories for that Epic.  Then, again, it doesn't matter on the Kanban boards - they just represent a flow of stories.

[Jason Ried]

If we made Character #1 an epic and then broke down the individual tasks though, then these wouldn't go through the Kanban as the individual tasks would be model, texture, rig, animate (which are the same as the columns in Kanban. So in this case the Kanban boards aren't very useful as the story is too granular. But I guess thats what you're saying right, it's about choosing one or the other.

I had gone down the kanban board based on your comments here: https://answers.atlassian.com/questions/38832686/how-do-i-use-a-transition-based-on-a-resolution

This was a great suggestion and seemed perfect until now 

I guess we now need to decide if we care about scrum points and finishing sprints more than the idea of tracking content through the system.

The ideal seems to now be if we could have Epics which go through the Kanban board, while we have stories which go through the scrum board. I guess thats not possible...?

[Nic Brough -Adaptavist-]

No, that's not what I'm getting at. .  For your setup the two types of board are aimed at different parts of your process.  You use the scrum board for planning and tracking.  The Kanban is a view to help you see what's happening and to allow you to move on through the process.

The whole point of both types of board is that you are able to track content.  The Scrum methodology gives you planning on top of that.

Epics and Stories are both relevant for both types of board.

[Jason Ried]

Okay, thanks.

For now we've decide to use Kansan boards as well as the scrum and just accept that our artists work won't fit into sprints. We will have to use another main tracker to ensure progress is on track, which is a pain, but seemingly the only way to be sure.

Thanks as always for the help Nic!