Task durations? Iterations?
Your product has got so much right, but several essential things wrong if it's something I'd use as a project manager. I'm telling you in the hope you'll take these ideas into account in a future release or let me know if they're not the roadmap you have for the project.
From the interface I've seen, there's nowhere for a developer to assign how long, in development hours or 'points', they think a task will take. Without that information it's impossible to determine what task should be worked on next: there could be 5 'Medium' priority tasks that can be done in the time of a single 'High' priority task.
The second thing is grouping tasks into iterations, sprints or releases. Related to my first point, this is the sensible way to organise tasks for me and I wonder if it's supported by Stacks.
If Stacks are shown across days based on the 'Due date' - what happens when the time they are needed by the schedule (set by the project manager) becomes out of sync with the time they can be done by, as predicted by the developer. You can say 'let them just chat' - but then something Stacks could help with has moved outside Stacks.
I'm also disappointed to see that to add a task you have to tell the interface the client and the project. Coming from a Basecamp background, you're already IN a client/project area so everything you do in there is implicitly related to that particular project.
If you could provide those features within the elegant 'Web 2.0' interface you've created here, I'd become interested in your product.
Adam
Comments are currently closed for this discussion. You can start a new one.
2 Posted by Tyler Morgan on 05 Mar, 2010 01:58 AM
Great points Adam. I second your idea for being able to add in estimated hours of completion in combination with the urgency field. Having Stacks suggest tasks to be completed based on the hours estimated for a tasks completion, the urgency of the task and the amount of time left before the task is due would be a huge feature. It's something I've never seen before and would really let me focus on doing rather than thinking about doing.
I've been trying out Stacks exclusively for a couple of days now. I had previously used Google Tasks in combination with my Google Calendar to manage my day to day tasks, due dates and appointments.
Seeing as how I don't really use the group functionality because I work by myself for a large majority of my projects, the only real benefit to using Stacks over my previous method is the dashboard view and sorting by client or project.
While I like the Stacks so far, in it's current status I personally wouldn't be able to justify the expense of a paid account versus the free Tasks/Calendar method.
3 Posted by Adam Knowles on 05 Mar, 2010 01:59 PM
I actually think 'Urgency' is a red herring - and, the way I work, would be removed. A task is either the next thing a particular person should do or it isn't. That's set by it's overall priority against every other thing that the person could do. Otherwise if you have 5 tasks all at 'Urgent' priority, with the same 'due' date: which should be done first: can Stacks answer that question methodically/objectively?
'Urgency' soon becomes meaningless. What's now, what's next. That's what people need to know.
I also think 'overdue' should go for the same reason - it doesn't provide actionable information i.e. is that thing that was meant to be finished yesterday still the priority? Then it's still live, but its 'due' date must be in the future to have any meaning.
It may be the way I/my team work isn't a way that Stacks is going to help with, but I hope it's food for thought.
Support Staff 4 Posted by Bruce Clark on 05 Mar, 2010 06:15 PM
Good discussion going on here, and some great points. I want to chime in with a few thoughts and questions.
First, in regard to the Basecamp model of being in a client/project vs. the Stacks model where there isn't a dedicated client/project area. This is simply a difference in how we approach managing tasks. The problem with a client/project area is that you don't know what else is going on until you move out of that area, it's harder to gauge what is happening with other clients and timelines. Stacks does require one extra step of adding this information to a task, but it saves time and adds functionality once the task is in the wild and needs to be filtered.
Second, we understand the need for a time estimation/completion section in Stacks. We've had several other discussions on this board regarding ways of approaching this. The main challenge is making sure that it's integrated fully while still offering a fast and simple method of control. Currently we use the task details and an external time tracker to do this, it's not the most elegant solution, but it keeps team members informed. We do envision adding this functionality, the only question is when. I can tell you honestly it's not going to be in the very near future. It's something that would help us greatly, so it is a priority, that said, we want to do it right and we have other action items that are already in progress ahead of it.
Third, in regard to urgency and overdue tasks. I see the point about urgency, in some cases it can seem pointless, especially with a lot of tasks that have the same urgency. The original idea behind urgency was a quick view of which tasks currently are most important based on the date they are due. In some cases, when multiple tasks due on the same day have the same urgency, external communication with the task assigner is required. That said, the "what's now, what's next" method seems a bit more cumbersome. What if a quick task gets added last minute, how is a "what's now, what's next" option visualized, and how does this work with multiple people editing each others tasks lists – not just one project manager? This conclusion we came to was that urgency was the best implementation of giving a task priority without removing control from the team environment. If there's a better method, that still allows for team control, we're all ears.
As for overdue tasks, we think this is important and that the current implementation makes sense. For example, if the task was due yesterday but actually wasn't a priority, then it needs to be moved back. We assume the initial due date was set for a reason. Changing due dates in stacks is super fast and can be done by anyone in the system, therefore, altering it to appear correctly in the stack shouldn't be a big deal. Further, if it did need to get done, then it should appear at the top of the stack as it's the most important item in relation to other tasks that are due later.
We're excited to keep improving Stacks. And we appreciate your guys feedback on this, we know there is definitely room to expand on our current functionality (or review and make changes to it) while still having a clean usable interface. Thanks for your feedback and ideas and feel free to comment further if there's something that we might not be thinking of.
Cheers,
Bruce
5 Posted by LaMond Woods on 16 Mar, 2010 06:50 AM
A need that I have is to be able to save client data entered in Stacks to a data base where all such information is saved for a long period of time. Since law governs the length of time my industry must save these records it would save double entry if when a task was complete I could export the data via email and PDF and save to our data base. Is this possible?
Also I am very excited to become a iPad user. Is any consideration being given for Stacks to utilize that platform?
Support Staff 6 Posted by Bruce Clark on 18 Mar, 2010 05:10 PM
Hi LaMond,
First, we do have plans for reporting capability and export in Stacks. The only option right now is printing the Stack list to PDF. This is obviously not a viable long term solution to reporting. We have designs and concepts in place for a reporting tab, but this is not something that will be released super soon. We're going to make time estimation a priority in its place.
Second, we are also interested in the iPad platform, that said, at this time we don't have time allocation set towards that. An iPhone/mobile app is higher on our radar and something we're already pursuing.
Hope this helps.
Bruce
7 Posted by Adam Knowles on 18 Mar, 2010 05:30 PM
Bruce, thanks for your considered responses. The main thing I do as a PM is make ordered lists and if you review my feedback in that light, you can observe that my complaints are where Stacks implements things that break the model of maintaining simple ordered list e.g. multiple to-dos with the same urgency and due-date.
I'll lay my cards on the table and say I want a great implementation of a web 2.0 task management system that matches Scrum. Stacks is attractive because it could become that. It sounds like the roadmap isn't in that direction, which is a shame.
Here's what I think would be needed to make it Scrum-compatible:
Final thought: since iPad apps can be souped-up iPhone apps, perhaps just consider during your iPhone app planning if there are quick wins you could implement to enhance the iPad experience.
Support Staff 8 Posted by Bruce Clark on 25 Mar, 2010 05:34 PM
Hi Adam,
Some great points. It does sound like Stacks may not be 100% on the level of what you're looking for with a task management solution. That said, we are addressing some of the things you've discussed.
First and foremost, we've prioritized time tracking and estimation to the top of the list. We will be allowing for allocated task time and actual time used. Further, you will be able to report on this data. As of now we're not sure how we'll be filtering this in the main Stack list, but it's an idea.
Due dates aren't something that will go away, it's too important to our workflow as a team and as of now you're the first person who has mentioned it being "too much" on a per task basis.
Third, the iPhone is high on our list (a lot of us here use them) but we are looking more at a mobile site vs. an iPhone app. This way it will be compatible with all webkit based phones. We'll see how things go.
I think I covered the rest of your questions perviously and I appreciate your responses and thoughts. Thanks for your time discussing this, I think you bring some good points to the table.
We wish you the best of luck with whatever task solution you go with.
Cheers,
Bruce
Bruce Clark closed this discussion on 25 Mar, 2010 05:34 PM.
Adam Knowles re-opened this discussion on 26 Mar, 2010 01:05 PM
9 Posted by Adam Knowles on 26 Mar, 2010 01:05 PM
Bruce, encouraging to know you take feedback seriously. I suppose my question is this. If you have a system such as Stacks, that system is an implementation of a theory of how project's can be managed. Which system or bit of a system/idea does Stacks map to?
If none, then you're proposing a new system, which is fine but not as strong as it being understood as part of a methodology with a history, maybe books about it, research and most importantly, testing on live projects.
So Stacks doesn't map to Scrum, though it's not far off - but does it match or suit any other PM methodology? If it did, it would be easier to understand it as a tool that can work within an established framework. That I would think would be a more powerful message than proposing a new, untested system for live projects.
Support Staff 10 Posted by Bruce Clark on 26 Mar, 2010 05:18 PM
Adam,
I'd like to bring in our PM to discuss that a bit more as I'm not up to par on PM jargon. Her name is Steph.
-Bruce
11 Posted by Lamond Woods on 26 Mar, 2010 05:22 PM
LaMond Woods
801.225.5000 (office)
801.438.9953 (Direct Line)
801.437.4720 (eFax )
-----Original Message-----
From: bruce.clark
[mailto:***@tenderapp.com]
Sent: Friday, March 26, 2010 11:18 AM
To: ***@sentrywest.com
Subject: Re: Task durations? Iterations? [Feature Suggestions]
Support Staff 12 Posted by stephanie.hoffman on 02 Apr, 2010 02:15 AM
Hey Adam,
I'm the Project Manager over at Imulus. When I first started here a couple years ago, Imulus introduced me to an alpha version of Stacks. I laughed that they were going to actually pay me to be a PM with a tool like that. I was used to numerous emails and meetings in my old companies, and that was when I was only managing 1 - 2 clients. Here, I manage a team of 10 people and over 30 clients. I use Stacks every day, and honestly wouldn't survive without it. That's not in any way intended to be an endorsement of our product, if it's not right for you. I just wanted you to know how much it helps me every day.
Having said that, there are clearly some great points you make and some differences in how we use it.
In your first post, you make a comment about hours or points. Our very next release is going to have time estimation and tracking. This upgrade is one of our highest priorities right now. It won't be part of the visual "stack," since stack items can show over multiple days. In terms of our business model there are 2 reasons we've shied away from making this an essential part of the visual:
It seems to micromanage the team too much. I want to have everyone accountable for their time, and make sure I'm aware of task duration. However, we're all grown-ups, and it's just as much my team's responsibility to conflict a task or come to me with timing concerns. As great as the visual is for me, it's good for my team too. They know when to push back.
I'm no programmer. I know basic HTML code, but that's where my expertise stops. So, some projects are over my head to "estimate" time. Instead of trying to guess when I assign a task, it has to be about open communication with my team. Stacks is a great tool to manage 90% of my projects, but it's no substitution for talking with my team. One of my favorite quotes: "The single biggest problem in communication is the illusion it has taken place."
So, yes, I see your concern and need for that, and I'm hoping the time estimation and tracking solves that issue for you.
I think this is along the lines of the urgency concern. It's my job to make sure my team knows what is "urgent." That can be a variety of things, from client importance, something's broken, it's late, whatever. I've actually requested this upgrade in the past. If there are 3 urgent tasks, what's really URGENT URGENT? However, once we discussed it, we got back to that level of micromanagement. Now, I may think client A needs task 1 done first, client B needs task 2 done second, and client A needs a 3rd task done next. For my developer, however, it may be more work to go from A to B back to A. So, in reality, he's going to make that decision no matter where I put it. So, ultimately, we thought this was the good way to go without defining every minute of our day. For a more "corporate" environment, that may be the way to go, but we just don't work well that way.
As for the due date shifter, I think down the road we may add some template options, and that may solve the problem. We've debated a lot about that. We don't want to end up with a lot of sub-projects within projects that are all connected because it becomes a bit of what is wrong with Basecamp. We want to make sure we don't get so granular that we lose the big picture. (Bruce explains this well in his post above).
Last, in terms of our theory...
We've used Basecamp, gantt charts, email, to-do lists, Things, etc. You name it. We've tried it. No tool out there provides a highly visual glance at an entire team's workload. This tool works great for a group of 5 - 10 people. It allows for very quick updates, subtle alerts, and simple filtering and prioritizing.
One of my biggest issues as a PM is knowing when to "nudge" my team. It's a sensitive area where you want to be on top of the client's needs without being a nag to your team. There's a constant role to play middle man and keep everyone happy. With Stacks, I receive an email or phone call from a client, immediately load the info into Stacks, file my email, and don't have to think about it again until I get an alert for completion. Every day, I can come in and get a progress without bugging my team, either by seeing overdue items, status updates, or conflicts. If a project needs to be escalated, I can quickly move other items around, increase urgency, and then, if needed follow up with an email or meeting. Also, I used to assign something to a team member and my old company, and then it was always "still on my plate" because I had to constantly remind myself to check in on it. With Stacks, once it's assigned, I can relax knowing the project is accounted for.
Anyway, sorry about the novel, but you brought up some really great points, and I wanted to address them all. I'd be happy to discuss more options or any other ideas you have to make Stacks better. It's people like you who will make this product better and better. We really appreciate the feedback!
Thanks,
Steph
13 Posted by svein.tore.ekre on 28 Apr, 2010 09:41 AM
What's the status on task time estimates? Will there be any updates soon?
Support Staff 14 Posted by Bruce Clark on 29 Aug, 2011 11:33 PM
Hi Svein,
We have a beta version with burdens (http://usestacks.com/blog/visualizing-the-weight-and-burden-of-task...) in close-to-release form right now. If you'd like to use this we can move you to the beta. Please submit a support request with your account details so it is private: http://usestacks.com/contact
Thanks,
Bruce Clark
Bruce Clark closed this discussion on 29 Aug, 2011 11:33 PM.
Svein Tore Ekre re-opened this discussion on 30 Aug, 2011 10:24 AM
15 Posted by Svein Tore Ekre on 30 Aug, 2011 10:24 AM
Hi
Unfortunately a specific time estimate and not just weighting will be necessary for us. But thanks for the information.
Mvh
Svein Tore
-----Opprinnelig melding-----
Fra: Bruce Clark [mailto:***@tenderapp.com]
Sendt: 30. august 2011 01:31
Til: Svein Tore Ekre
Emne: Re: Task durations? Iterations? [Feature Suggestions]
Support Staff 16 Posted by Bruce Clark on 02 Sep, 2011 09:02 PM
Yeah, in that case you'd still need to add it via details. We found that the complexity of explicit estimates was extremely difficult. It starts of simple but by the time you're done thinking through the possible scenarios it's become quite bloated and hard to implement.
Thanks for your insight though.
Bruce
Bruce Clark closed this discussion on 02 Sep, 2011 09:02 PM.