I love scrum. Done right, tasks are small enough that they fit into a 1 week sprint. Because of the unknowns of software development, sometimes your first step is figuring out the first step. How do you write acceptance criteria for that?
Basically, you need a ticket to allow you to sit back and think about the project. How do you write a ticket for that?
Yes, do some Hammock Driven Development!
Develop Better Software: Turn a 1 Week Ticket into a 3 Week Ticket
Software takes time to get right. It’s not about the number of hours actually typing out the code. Getting software right means building the feature that solves the problem. That means spending time doing requirements gathering, both with people and with software. To avoid wasting time building the wrong thing, you talk to people. To avoid re-inventing the wheel, you may research similar solutions first.
Week 1: A Spike Ticket to Strategize
Regardless of what kind of research you need to do, you need time to do that. That means, time to create a SPIKE ticket. More on spikes in scrum here. I disagree that they should be the exception, however.
I don’t know if it really matters if you call it a spike. What matters is that you have the time to do the thinking work, and a ticket that reflects that work. You can use business words like strategize in the ticket name. Synonyms for strategize include diagram, form, sketch, formulate, plan, etc. If you need concrete acceptance criteria, you could create some object models with UML diagrams. Or perhaps you could create new tickets for next steps.
Week 2: The actual work, and tests for it.
In addition to actually typing out the solution, week 2 should include the software developer testing her solution, both with manual testing and also by writing unit tests.
I could see the necessity of creating a separate ticket for writing the unit tests, in some cases. It depends how big of a feature is being built and how important the tests are. Is failure a mission critical issue?
Week 3: QA
Quality Assurance (QA) is when someone tests your work to see if it meets the acceptance criteria. I’d say that to not rush QA, it should be its own separate task, and reviewing QA feedback and fixing any issues should happen in this third week.
A “1 Week Sprint” is only 5 business days. If QA has to be done before the end of the sprint, then the task has to be done in 4 days or less. I’d argue that it takes time to develop software correctly, and this includes thinking time. It takes a lot of mental concentration and focus to hold complex abstractions in your head, and better software is developed when you have time to take breaks. Taking a break and re-reading my code later, or literally sleeping on it, has made a world of difference.
There’s also code review time to consider. Assuming that you do code review, you have to get that done within 5 days too. In an ideal world, there would be time to think about the reviewer’s suggestions, and implement them in the best way possible, instead of rushing to apply the reviewer’s feedback.
Rushing is an easy way to break something, and saves no time at all.
So, between thinking time, coding time, and review time, 5 business days is a short time period to implement a brand new software feature. This assumes that the ticket is just one of several that the developer has to handle, in addition to meetings and putting out fires when urgent issues arise.