7 ms·

How we run our agile dev process using only Trello and Google Docs

163 points by rrwhite 14y ago

iusable 14y ago
Respect! We just turned every other 'project management' app off but Trello (goals/tasks/bugs/feedback) & Beanstalk (repo);
endeavor 14y ago
Very cool! 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.
- TootsMagoon 14y ago
  I'm curious about their thoughts on Pivotal as well. In addition, how do you track velocity?
  - adrianhoward 14y ago
    In addition, how do you track velocity? From the description it doesn't look like they're running in sprints, but deploying as stories get completed, so cycle time would be the thing they would track. No idea if Trello can do this out of the box. They also explicitly said that they're not doing project estimates - so they wouldn't need to track velocity in any case. If it were me I might be interested in visualising the flow somewhere - more of a tool to help spot problems as to make estimates any more accurate - but I'm a fan of just doing that with a whiteboard as part of running the project.
- rrwhite 14y ago
  It's been a long time since I checked out Pivotal so I don't feel that confident in giving too much of an opinion. However my main gripe with Pivotal was always two things: 1) Strict adherence to a Scrum methodology (forcing me to use a certain set of columns, etc) and 2) The UI. It frankly drove me nuts. The small text fields, small text areas and lack of wiki-style formatting. Anything longer than a few words was impossible to grok. We flirted with trying it out about the time we adopted Trello but enough people had bad past experiences, like mine, that we never gave it a try.
  - endeavor 14y ago
    Yeah I hear you. We use Pivotal for a few projects and my top two complaints are the same as yours, although they've made some improvements in the last few months. OTOH there are things that bother me about the Trello UI as well. Thanks for replying!
rollypolly 14y ago
How big of a team / project could be managed reasonably with this process?
- DanielBMarkham 14y ago
  Agile teams are 5-7 people. Perhaps you mean how many people in total? I've seen lightweight systems like this scale out to 150+ developers. (Insert discussion here about Agile Program Management) You really don't need a lot. Most enterprise project management systems are over-engineered by a couple orders of magnitude. (And they hurt much more than they help)
  - endeavor 14y ago
    My expectation would be that you would still have one central PM and Planning board but you'd have a separate Current Development board for each team (i.e. different teams for different components/modules).
    - DanielBMarkham 14y ago
      Yep, that's pretty close. There are some considerations with teams-of-teams. Infrastructure, suppliers, scheduling, production support, release procedures, etc. There is also a bit of organization and dynamic scaling necessary: you don't want a program backlog with 4 thousand items on it. That's unworkable. Usually it helps if you stay with fixed iterations instead of Kanban and do program planning all at once (Yes, 150 people all in the same room working out the next couple of sprints. Fun to watch and participate in!) Other kinds of tooling issues become bigger in a large group, like how to integrate separate physical pieces, how many branches to have in your CM tool, how technical drawings will be cataloged, etc. But none of it is super hard, and lots of other folks have already gone down this road. The important thing is not to over-constrain your development environment just to make yourself feel safer. The biggest obstacle to running a larger group like this is dealing with the parts that are counter-intuitive. It just seems natural with 100 folks that you'd have a detailed charge-code breakdown, for instance. Or that 100% capacity is something you want to achieve. There are a few more gotchas like this, but if people are open-minded, it can mean a huge increase both in performance and happiness. The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better. Note I didn't say you couldn't go total kanban at large scale, just that there was a trade-off involved with each path.
tlogan 14y ago
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.
- adrianhoward 14y ago
  You wouldn't see them on my board either - for a few reasons (hopefully none of them scary :-) * We view design as an ongoing and continual process - not a phase. Having a "software design phase" just wouldn't make sense for us since it basically covers the whole cycle from when the idea comes out to when it hits the streets. * We generally pair on development where at all possible, and when we are pairing we don't find that we get a great deal of additional value out of code reviews on top. * When we don't pair for whatever reason we do code reviews, but do them on a regular cadence rather than as a phase (say every Wednesday afternoon). A bunch of stuff fits in this kind of pattern. We are sure to talk to users every couple of weeks. We do some usability testing every couple of weeks. It's not related to how stories flow so it's not on the board.
  - iusable 14y ago
    "We view design as an ongoing and continual process - not a phase." - Boom! Wish I could do more than just one vote up.
  - tlogan 14y ago
    The reason to have a dedicated "software design phase" is to encourage invention of "nobody can do it but us" - secret sauces which can make you (or your company) super rich (i.e., algorithms in Oracle Database, Google's algorithms, etc.). These things cannot be invented as "ongoing and continual process". I know that my examples are based on system software development, but I have no reason to believe they cannot be applied also for web development.
    - donw 14y ago
      That's more R&D than part of the day-to-day engineering process, though. Anything that's going to be secret sauce is going to need a lot of prototyping and experimentation, and might not even yield usable results. Oftentimes, it isn't even possible to make an estimate as to the complexity of what it is you are building -- all you can do is timebox it. Mixing that in with normal day-to-day development feels, to my brain, like mixing concerns. Once those prototypes and experiments start to produce tangible benefits, then incorporating them just becomes another story in the sprint.
chintan 14y ago
> Don’t have a separate system for bugs 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. > It’s the product development version of the Hunger Games :)
- evanhamilton 14y ago
  Ah, it's worth clarification here. Here's how we use the nomenclature: Ticket - a message a customer sends in about an issue or question. Bug - an issue (that can come from any source) which we track and resolve. We just Trello for bugs (which may be reported in tickets) but we use UserVoice Helpdesk (http://www.uservoice.com/helpdesk http://www.uservoice.com/helpdesk) for tickets. Helpdesk is designed around customer communication, Trello is designed around development. Hope that clarifies! :)
jmartens 14y ago
Great post. Trello is amazing. We are also a Trello/Google Doc company, but not as fancy as Uservoice.
neilkelty 14y ago
What does the "Roadmap" Board look like? (e.g. List titles)
- rrwhite 14y ago
  There's simple a column for each quarter (ex: 2012 Q3) going about 3 quarters into the future. The only things on this board are big strategic projects.
hkarthik 14y ago
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. 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. 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. 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.
- lucisferre 14y ago
  Yeah I pretty much echo this experience. The ironic part is how almost every "Agile" company I've ever seen seems to completely reverse the very first line of the manifesto. > Individuals and interactions over processes and tools For my part, I'm completely done with Agile and the Agile community, there is very little of value there any more. Those who did add value have moved on, tired of and pushed out by those looking to make a quick buck consulting or managers looking to justify their poor management skills. It's quite sad. I'm on a small team now, doing something fun and cool. The process is leaner, faster, way more productive and without all the BS overhead of trying to be "Agile".
  - dclaysmith 14y ago
    I wrote a blog post last week that echos this sentiment. Funny how (many) people who (and tools that) espouse agile actually fail the first tenet of the agile manifesto.... (not meant as a plug but for those interested in reading .... http://www.thetaboard.com/blog/why-im-haking-thetaboard?r=376 http://www.thetaboard.com/blog/why-im-haking-thetaboard?r=37...)
  - adrianhoward 14y ago
    For my part, I'm completely done with Agile and the Agile community, there is very little of value there any more I don't think it's quite that bad myself, but I think it depends which bits of "the community" you find yourself in. There are still smart folk who do actually pay attention to the manifesto and don't wander around applying an "agile" label to everything around them and carrying on as before ;-)
ams6110 14y ago
How many would like to be doing something like this but cannot have customer or product data in third party/"cloud" storage? Is there anything like Trello that can be run in-house?
- 8ig8 14y ago
  A whiteboard and a big pack of colored sticky notes works for this. It might sound simplistic, but it's surprising effective. It's difficult to ignore the big board if you hang it in a public area of the office. Pretty shallow learning curve also helps. I actually think if you're trying to get people to buy in to a methodology such as this, it's easier to start with a physical board and progress to something like Trello. One step at a time.
  - adrianhoward 14y ago
    It's difficult to ignore the big board if you hang it in a public area of the office If I have more than one up-vote to give... this would get it. I find people really underestimate the value of a physical board setup. I agree that it's a vastly better starting point than online tools for most teams if they're in the same location.
burtlo 14y ago
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? Many thanks for a thought-provoking, and wonderfully complete, post.
- embwbam 14y ago
  A PM can often estimate delivery timetables by analyzing historical lead time. For example, if it normally takes 10 days for a 2-star card to move from Next Up to LaunchPad, then you can guess when it will get shipped. Pad it a little, and make sure you give yourself time to get it IN to the next up column, and you're good.
  - burtlo 14y ago
    I was wondering if you had some compelling (magical?) communication that shifted your clients attitudes, but you're basically guesstimating based on past performance. I didn't see where a star rating equated to effort. I'll look again. Thanks!
- rrwhite 14y ago
  We're a SaaS business so I don't think there's much we need to do here. We launch/promote something only when it's ready. The only deadlines we operate on are internal (ex: we need feature X in time for event B).
- adrianhoward 14y ago
  How have you trained your customers to NOT expect estimates? If you try this sort of thing yourself what you'll often find is that you can get the cycle time of stories (the time from the story going on the board, to the time it gets deployed) to be fairly constant. It can take some work to get top this point, but it's possible and useful in almost all circumstances. Once you get to this point you can pretty confidently predict that stories are 1week/1month/2months away from getting deployed - and you can use this as the basis you base customer estimates on. Arlo Belshee coined this style and called it "Disney Line" planning (y'know - like the one-hour wait from this point thing). Arlo has a great video on this sort of approach to planning http://www.youtube.com/watch?v=6t4bZtnnQJA http://www.youtube.com/watch?v=6t4bZtnnQJA that might be worth a watch.
embwbam 14y ago
Do you have a Work in Progress limit?
- adrianhoward 14y ago
  They seem to have individual ones, rather than stage based ones - from the original post: Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
productmanager 14y ago
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.
- adrianhoward 14y ago
  If you're not getting a pretty constant velocity (if you're going the sprint route) or cycle time (the kanban/flow route) then no tool is going to make that happen. I confidently predict that if Pivotal is not helping you now, Jira will not help you in the future. What needs to change is how the team works, or maybe management's expectations of the team. Not the tool.
  - productmanager 14y ago
    agree.. technically the velocity should be constant and more or less is.. but the story estimates still establish the building blocks for this.. a story seems to need tasks and task estimates to make the overall story estimate more accurate. Tasks help to break up activities. alternative is to groom the story of course, then you're left with a larger list of stories to manage however, and taking care of that in turn eats into our PM team's velocity :)
    - adrianhoward 14y ago
      It sounds like your spending a lot of effort on estimating. I'd guess (I'm not there so probably incorrectly :-) that you've got some combination of: a) stories being too big b) stories having to much variation in size c) doing time based estimation rather that relative estimates or story counting.
- Volpe 14y ago
  They are supposed to have a hard time estimating a few months out. Predicting the future is hard.
simonswords82 14y ago
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 (http://www.staffsquared.com http://www.staffsquared.com) 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. 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.
neilkelty 14y ago
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?
blueskittle 14y ago
What labels are used on the Product Planning Board?
benr 14y ago
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. 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.
- dejanabdejana 14y ago
  Several things can happen with a card that's in the inbox: it can go to Roadmap, Planning, Engineering, Current Development, or just be archived if it's not something we can prioritize at the moment. Bugs have a separate board, so they usually don't end up in the Inbox. Most of our customers' ideas live on our UserVoice feedback forum (feedback.uservoice.com). If an issue comes up during the Inbox review meeting and we don't plan on implementing the solution the next 3 Q's, we archive the card, or create an idea on our forum (if not there already). The key here is that people are encouraged to bring up that exact same issue next week, if it's still something that creates a lot of buzz among our customers. That helps us understand what the current pain points are and prioritize cards accordingly.
jodeci 14y ago
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? :)

163 points by rrwhite 14y ago

Respect! We just turned every other 'project management' app off but Trello (goals/tasks/bugs/feedback) & Beanstalk (repo);

endeavor 14y ago

Very cool! 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.

TootsMagoon 14y ago
I'm curious about their thoughts on Pivotal as well. In addition, how do you track velocity?
- adrianhoward 14y ago
  In addition, how do you track velocity? From the description it doesn't look like they're running in sprints, but deploying as stories get completed, so cycle time would be the thing they would track. No idea if Trello can do this out of the box. They also explicitly said that they're not doing project estimates - so they wouldn't need to track velocity in any case. If it were me I might be interested in visualising the flow somewhere - more of a tool to help spot problems as to make estimates any more accurate - but I'm a fan of just doing that with a whiteboard as part of running the project.
rrwhite 14y ago
It's been a long time since I checked out Pivotal so I don't feel that confident in giving too much of an opinion. However my main gripe with Pivotal was always two things: 1) Strict adherence to a Scrum methodology (forcing me to use a certain set of columns, etc) and 2) The UI. It frankly drove me nuts. The small text fields, small text areas and lack of wiki-style formatting. Anything longer than a few words was impossible to grok. We flirted with trying it out about the time we adopted Trello but enough people had bad past experiences, like mine, that we never gave it a try.
- endeavor 14y ago
  Yeah I hear you. We use Pivotal for a few projects and my top two complaints are the same as yours, although they've made some improvements in the last few months. OTOH there are things that bother me about the Trello UI as well. Thanks for replying!

rollypolly 14y ago

How big of a team / project could be managed reasonably with this process?

DanielBMarkham 14y ago
Agile teams are 5-7 people. Perhaps you mean how many people in total? I've seen lightweight systems like this scale out to 150+ developers. (Insert discussion here about Agile Program Management) You really don't need a lot. Most enterprise project management systems are over-engineered by a couple orders of magnitude. (And they hurt much more than they help)
- endeavor 14y ago
  My expectation would be that you would still have one central PM and Planning board but you'd have a separate Current Development board for each team (i.e. different teams for different components/modules).
  - DanielBMarkham 14y ago
    Yep, that's pretty close. There are some considerations with teams-of-teams. Infrastructure, suppliers, scheduling, production support, release procedures, etc. There is also a bit of organization and dynamic scaling necessary: you don't want a program backlog with 4 thousand items on it. That's unworkable. Usually it helps if you stay with fixed iterations instead of Kanban and do program planning all at once (Yes, 150 people all in the same room working out the next couple of sprints. Fun to watch and participate in!) Other kinds of tooling issues become bigger in a large group, like how to integrate separate physical pieces, how many branches to have in your CM tool, how technical drawings will be cataloged, etc. But none of it is super hard, and lots of other folks have already gone down this road. The important thing is not to over-constrain your development environment just to make yourself feel safer. The biggest obstacle to running a larger group like this is dealing with the parts that are counter-intuitive. It just seems natural with 100 folks that you'd have a detailed charge-code breakdown, for instance. Or that 100% capacity is something you want to achieve. There are a few more gotchas like this, but if people are open-minded, it can mean a huge increase both in performance and happiness. The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better. Note I didn't say you couldn't go total kanban at large scale, just that there was a trade-off involved with each path.

tlogan 14y ago

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.

adrianhoward 14y ago
You wouldn't see them on my board either - for a few reasons (hopefully none of them scary :-) * We view design as an ongoing and continual process - not a phase. Having a "software design phase" just wouldn't make sense for us since it basically covers the whole cycle from when the idea comes out to when it hits the streets. * We generally pair on development where at all possible, and when we are pairing we don't find that we get a great deal of additional value out of code reviews on top. * When we don't pair for whatever reason we do code reviews, but do them on a regular cadence rather than as a phase (say every Wednesday afternoon). A bunch of stuff fits in this kind of pattern. We are sure to talk to users every couple of weeks. We do some usability testing every couple of weeks. It's not related to how stories flow so it's not on the board.
- iusable 14y ago
  "We view design as an ongoing and continual process - not a phase." - Boom! Wish I could do more than just one vote up.
- tlogan 14y ago
  The reason to have a dedicated "software design phase" is to encourage invention of "nobody can do it but us" - secret sauces which can make you (or your company) super rich (i.e., algorithms in Oracle Database, Google's algorithms, etc.). These things cannot be invented as "ongoing and continual process". I know that my examples are based on system software development, but I have no reason to believe they cannot be applied also for web development.
  - donw 14y ago
    That's more R&D than part of the day-to-day engineering process, though. Anything that's going to be secret sauce is going to need a lot of prototyping and experimentation, and might not even yield usable results. Oftentimes, it isn't even possible to make an estimate as to the complexity of what it is you are building -- all you can do is timebox it. Mixing that in with normal day-to-day development feels, to my brain, like mixing concerns. Once those prototypes and experiments start to produce tangible benefits, then incorporating them just becomes another story in the sprint.

chintan 14y ago

> Don’t have a separate system for bugs 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. > It’s the product development version of the Hunger Games :)

evanhamilton 14y ago
Ah, it's worth clarification here. Here's how we use the nomenclature: Ticket - a message a customer sends in about an issue or question. Bug - an issue (that can come from any source) which we track and resolve. We just Trello for bugs (which may be reported in tickets) but we use UserVoice Helpdesk (http://www.uservoice.com/helpdesk http://www.uservoice.com/helpdesk) for tickets. Helpdesk is designed around customer communication, Trello is designed around development. Hope that clarifies! :)

jmartens 14y ago

Great post. Trello is amazing. We are also a Trello/Google Doc company, but not as fancy as Uservoice.

neilkelty 14y ago

What does the "Roadmap" Board look like? (e.g. List titles)

rrwhite 14y ago
There's simple a column for each quarter (ex: 2012 Q3) going about 3 quarters into the future. The only things on this board are big strategic projects.

hkarthik 14y ago

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. 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. 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. 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.

lucisferre 14y ago
Yeah I pretty much echo this experience. The ironic part is how almost every "Agile" company I've ever seen seems to completely reverse the very first line of the manifesto. > Individuals and interactions over processes and tools For my part, I'm completely done with Agile and the Agile community, there is very little of value there any more. Those who did add value have moved on, tired of and pushed out by those looking to make a quick buck consulting or managers looking to justify their poor management skills. It's quite sad. I'm on a small team now, doing something fun and cool. The process is leaner, faster, way more productive and without all the BS overhead of trying to be "Agile".
- dclaysmith 14y ago
  I wrote a blog post last week that echos this sentiment. Funny how (many) people who (and tools that) espouse agile actually fail the first tenet of the agile manifesto.... (not meant as a plug but for those interested in reading .... http://www.thetaboard.com/blog/why-im-haking-thetaboard?r=376 http://www.thetaboard.com/blog/why-im-haking-thetaboard?r=37...)
- adrianhoward 14y ago
  For my part, I'm completely done with Agile and the Agile community, there is very little of value there any more I don't think it's quite that bad myself, but I think it depends which bits of "the community" you find yourself in. There are still smart folk who do actually pay attention to the manifesto and don't wander around applying an "agile" label to everything around them and carrying on as before ;-)

ams6110 14y ago

How many would like to be doing something like this but cannot have customer or product data in third party/"cloud" storage? Is there anything like Trello that can be run in-house?

8ig8 14y ago
A whiteboard and a big pack of colored sticky notes works for this. It might sound simplistic, but it's surprising effective. It's difficult to ignore the big board if you hang it in a public area of the office. Pretty shallow learning curve also helps. I actually think if you're trying to get people to buy in to a methodology such as this, it's easier to start with a physical board and progress to something like Trello. One step at a time.
- adrianhoward 14y ago
  It's difficult to ignore the big board if you hang it in a public area of the office If I have more than one up-vote to give... this would get it. I find people really underestimate the value of a physical board setup. I agree that it's a vastly better starting point than online tools for most teams if they're in the same location.

burtlo 14y ago

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? Many thanks for a thought-provoking, and wonderfully complete, post.

embwbam 14y ago
A PM can often estimate delivery timetables by analyzing historical lead time. For example, if it normally takes 10 days for a 2-star card to move from Next Up to LaunchPad, then you can guess when it will get shipped. Pad it a little, and make sure you give yourself time to get it IN to the next up column, and you're good.
- burtlo 14y ago
  I was wondering if you had some compelling (magical?) communication that shifted your clients attitudes, but you're basically guesstimating based on past performance. I didn't see where a star rating equated to effort. I'll look again. Thanks!
rrwhite 14y ago
We're a SaaS business so I don't think there's much we need to do here. We launch/promote something only when it's ready. The only deadlines we operate on are internal (ex: we need feature X in time for event B).
adrianhoward 14y ago
How have you trained your customers to NOT expect estimates? If you try this sort of thing yourself what you'll often find is that you can get the cycle time of stories (the time from the story going on the board, to the time it gets deployed) to be fairly constant. It can take some work to get top this point, but it's possible and useful in almost all circumstances. Once you get to this point you can pretty confidently predict that stories are 1week/1month/2months away from getting deployed - and you can use this as the basis you base customer estimates on. Arlo Belshee coined this style and called it "Disney Line" planning (y'know - like the one-hour wait from this point thing). Arlo has a great video on this sort of approach to planning http://www.youtube.com/watch?v=6t4bZtnnQJA http://www.youtube.com/watch?v=6t4bZtnnQJA that might be worth a watch.

embwbam 14y ago

Do you have a Work in Progress limit?

adrianhoward 14y ago
They seem to have individual ones, rather than stage based ones - from the original post: Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.

productmanager 14y ago

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.

adrianhoward 14y ago
If you're not getting a pretty constant velocity (if you're going the sprint route) or cycle time (the kanban/flow route) then no tool is going to make that happen. I confidently predict that if Pivotal is not helping you now, Jira will not help you in the future. What needs to change is how the team works, or maybe management's expectations of the team. Not the tool.
- productmanager 14y ago
  agree.. technically the velocity should be constant and more or less is.. but the story estimates still establish the building blocks for this.. a story seems to need tasks and task estimates to make the overall story estimate more accurate. Tasks help to break up activities. alternative is to groom the story of course, then you're left with a larger list of stories to manage however, and taking care of that in turn eats into our PM team's velocity :)
  - adrianhoward 14y ago
    It sounds like your spending a lot of effort on estimating. I'd guess (I'm not there so probably incorrectly :-) that you've got some combination of: a) stories being too big b) stories having to much variation in size c) doing time based estimation rather that relative estimates or story counting.
Volpe 14y ago
They are supposed to have a hard time estimating a few months out. Predicting the future is hard.

simonswords82 14y ago

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 (http://www.staffsquared.com http://www.staffsquared.com) 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. 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.

neilkelty 14y ago

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?

blueskittle 14y ago

What labels are used on the Product Planning Board?

benr 14y ago

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. 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.

dejanabdejana 14y ago
Several things can happen with a card that's in the inbox: it can go to Roadmap, Planning, Engineering, Current Development, or just be archived if it's not something we can prioritize at the moment. Bugs have a separate board, so they usually don't end up in the Inbox. Most of our customers' ideas live on our UserVoice feedback forum (feedback.uservoice.com). If an issue comes up during the Inbox review meeting and we don't plan on implementing the solution the next 3 Q's, we archive the card, or create an idea on our forum (if not there already). The key here is that people are encouraged to bring up that exact same issue next week, if it's still something that creates a lot of buzz among our customers. That helps us understand what the current pain points are and prioritize cards accordingly.

jodeci 14y ago

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? :)