I really dig this post. I've worked at waterfall companies and agile companies doing Scrum, and in both places the tools tended to dictate the process a bit too much for my liking.<p>Estimates got treated as gospel and planning was deemed extremely important, but nobody was willing to make the time for it to be done right.<p>I think web apps with shorter release cycles and fast deployments can really benefit from a process like this. You just have to be willing to try out simple, light weight tools and iterate on the process just like you iterate on the code.<p>Most shops tend to just use what they know rather than attempt to hack the process to meet their own needs. Kudos to the guys at UserVoice for going against the grain.
Very cool!<p>I assume you've tried Pivotal Tracker at some point too? I'd be interested to know what you like/dislike about your new workflow compared to Pivotal.
The interesting part (or scary part if you ask me) in all this workflows and meetings there is no space for software design specification and code review.
> Don’t have a separate system for bugs<p>This is very interesting. We also use Google Docs for stories/specs and Trello for prioritization and roadmap. However, we maintain a separate bug tracker (Open Atrium) for our enterprise clients to report bugs. We'd also love to have a single prioritization list. Wish there was an ability to create a Trello list sync'd with RSS Feed from Open Atrium.<p>> It’s the product development version of the Hunger Games<p>:)
Great post and just the right level of detail too. Thanks for taking the time to write this up. We're just about to encounter this problem with our own startup (<a href="http://www.staffsquared.com" rel="nofollow">http://www.staffsquared.com</a>) and my head of ops has been on my back for weeks about how we're going to handle our roadmap for the product vs. bug fixes vs. user feedback.<p>One point I would make as a brand new start up - I'm not sure how willing/able I'd be to handle the uncertainty of not forcing my dev team to tell me the number of hours a fix/feature will take to implement. I say this because sometimes our road map will include a feature request that upon receiving an estimate for I then decide not to proceed with as the cost/benefit ratio doesn't add up. When this happens I de prioritise the task and put it in a backlog. Having said that, we're at the stage where every second counts; perhaps when we've got a steady stream of income I'll be less picky.
How have you trained your customers to NOT expect estimates? What's your model for billing and managing budget, strictly Time and Materials, or do you valuate the Planned Deliverables?<p>Many thanks for a thought-provoking, and wonderfully complete, post.
How many would like to be doing something like this but cannot have customer or product data in third party/"cloud" storage?<p>Is there anything like Trello that can be run in-house?
We've been using Pivotal, but are about to switch over to Jira completely. Tried Trello. At end of day Trello and Pivotal are lacking 2 key features we need for better predictability in scrum, particularly on enterprise software with many projects: tasks with t-shirt/time estimates, and burndown charts. Without these, the PM team has a hard time estimating a few months out what is possible.
What happens to the cards on the Inbox board during the Inbox review meeting? I assume some are moved onto the planning board, others onto the bugs board.<p>But what about a feature request from a customer that you don't plan on implementing in the next 3 quarters? Do you just delete those cards, or move them to some other backlog.
You mention that each week has it’s own Live column; do you only keep The Current Week on the current development board? What happens to the older weeks, are they just archived or moved to another board? :)
Any insight on how you prioritize cards? Do you keep the process as simple as "I think A is more important than B, but less important than C." or do you use some sort of scoring mechanism?