Stories - how small is too small

Today over on the Scrum Development forum a question was posted by a member. They have a situation where they have mixed some small stories with some larger ones. And the larger one is LATE - Really late. It's now been pushed into the 3rd Sprint and according to her it's still tight. So now they're faced with a situation where the smaller stories that are done can't be deployed as they never branched the code.

I find it alarming that folks can't break user stories down further. So many folks say you can't do it when over on the XP forums they're all working with really small stories so much so that they don't even bother with tasks any more.

So what does she do in this scenario. Well I suggest that 1. You try your hardest to break stories down as much as possible. At a minimum they should be of the size that you have close to 100% certainty (I know there is no such thing) of getting it done during the active sprint.

Now if you do have a large risky story mixed with smaller ones that you definitely want to go live on production servers at the end of the sprint then you have to plan ahead of time and ensure that the code is properly branched.

So how small is too small. In my opinion, stories need to be understood by customers, the client or PO's. They can't be or shouldn't be at the level of tasks that can't be understood by anyone other than a developer.

But erring on the side of smaller is definitely better and more manageable.

Let me know your thoughts.
Jack

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com