Hans Dahlström: how can I recognize the version I am using? For me the function is not yet available?

Patrick Egloff: How does it look if you open a card? you should see the dependencies table like this (if you press the tab Dependencies)

After a reload now it works - Great :-)

Hans Dahlström: Thanks to the whole team for the implementation of this really great feature. I like the way it looks and works. And also thanks to the community supporting the process of creation :*

Hans Dahlström: Hi, I'm loving the dependencies feature but would really like some enhancements to make it amazing... Add automations so we can do things like -

* When a cards status has changed from 'doing' to 'done' remove 'blocked' tags on child cards under this parent card.

* Add a lock/unlock feature so nobody can work on a child card/s if the parent isn't complete

Hans Dahlström: Love it! I immediately realized I hadn't found all my feedback during the beta though. The first thing I did was to go into a card, click "Add before/after" and look for the "New" button to create a card for the thing I realized I needed to complete before I could move this card forward.

Hans Dahlström: The Gif is showing the Parent connection, which I really like, But if I open the Epic card, I right now do not see the child cards, that is what I am missing.

What we want is; When I open the "epic card" which is our roadmap level, we see what stories and tasks in "childs" in that epic, and can track progress on that in our roadmap.

Pretty much, we don't only want to see perents, we also want to look at parent cards and see all childs.

will the new relations update reflect that?

I have figured out how we can do this. It's not ideal, from our point of view, but it might work for us.

We us the "on board" part for connecting a Epic to a Feature and a story to an Epic. But use dependencies to connect tasks with the story.

Though this does not help me look at an epic and see child cards (Story) without having to put dependencies there also. I only se parent card (feature)

Christian Ahlin: Thanks for reporting!

Dovidas Baranauskas: I've left a ton of feedback now.

Hans Dahlström: Hej Hans, I like it :)

Hans Dahlström: Looks really good in general. I could foresee two UX challenges here:

a) The terms "Before" and "After" are potentially vague. You use them in the meaning of "Cards Before this one" and "Cards after this one" i think, but they could easily be interpreted as "Card is before these" and "Card is after these". The icons help, but I still think there might be uncertainty here

b) The section of dependencies might grow long and start to push the description of the card down below the fold. I already have this problem on boards with many custom fields. A way to collapse part of the content above the card description will come in handy.

Johan Bouvin: I understand your issues, but I think you will learn to handle this, especially what "before" and "after" means. The collapsing thing is displayed above. You can see the buttons for "On boards" and "Dependencies". So when it's collapsed you will have more space above the content than in the current design. :)

Hans Dahlström:

Great to see some progress!

If you're only asking for the color/format of the line, the transparent is the least annoying. Maybe even a solid grey color throughout would be better. But overall - having lines in the kanban could get messy. But with a toggle button, it could work.

But maybe I don't understand the dependency solution here as I'm a bit confused as to how to interpret dependency in this Kanban view. As alluded to in a longer comment I made below, there are two aspects of dependency: either its in relation to time or its in relation to the "completeness" of a task. I get the impression that you kind of try to solve both here...?

For the timing aspect, what's good about having normal gantt chart dependency lines (see Branline Mexico's mockup below), is that when you move a card around in a timeline view, it will consider the other connected cards making planning more efficient. This is THE efficiency gain instead of having to move lots of cards in relation to some other change.

For the completeness aspect, what's important, imo, is that whenever a task is completed (that I depend on before I can move on) it should be clear to me somehow that this is the case. Most likely by the use of automation.

Example: there's a card C in a backlog which the project manager controls. Card C cannot be started until card A and B are done. So, one solution here would be setting up a workflow so that when A and B have completed, i.e. the connected dependencies to C are done, then card C can be moved out to the TODO column and I can start work on it.

Hans Dahlström: "Consistent out/input..." just looks messy.

"Shortest path lines with transparent lines" looks best for normaly usage.

Hans Dahlström: I am generally not a fan of having lines all over boards as the primary method to work with dependencies. Of the given choices, I prefer the transparent lines of the since it is least visually overwhelming. If implemented, I would hope this is toggleable.

What I would find useful would be to display an icon/indicator on cards that are part of a dependency chain and being able to show that dependency chain via a context option on the card. I would also like automation that would restrict cards that are part of a dependency chain from progressing until the preceding card has reached a designated status as well as notifications of PMs and card owners when cards in a chain are late and affecting subsequent cards.

Hans Dahlström: good to see some progress! to be honest, i don't like any of them. the overlapping lines are an eye sore no matter what style you give it. the lines should change so that they do not overlap. i think dependencies need their own view altogether i.e. a dependency graph/ flowchart/ mind map to toggle just as we're able to toggle from backlog/ kanban/ timeline. definitely need to show on a timeline view but again, the overlapping lines create a lot of confusion and should probably change to straight/angle so no overlap occurs. also would want to see dependency cards on the back of cards similar to how we see card attachments but maybe in a more elegant form. to sum up, this is what i'd want to see:

I've included some screenshots below for some ideas.

i know this is a tough one to pull off but i have complete faith in you guys! keep up the great work!!

Hans Dahlström: Shortest path transparent would be my preference, but they all look a little messy to me. :(

However, how would this look if the dependent cards exist on a different board?

And what does the defining the dependency look like within each card? Will that work similarly to linking to another favro card, except with some kind of dependency flag?

Jay Halderman: +1 - this is what I had in mind

Nicki: that's also what i suggest.., to create an entirely different Dependency View altogether. It would basically be a "board view" like we have for backlog/kanban/timeline now.

To create a dependency, I think their could be a few different approaches. I initially thought that "grouping" cards together would automatically make them dependencies of that "group" card like in my screenshot below..but i could see how that wouldn't work for all scenarios. here's some of my ideas for that:

Hans Dahlström: Thanks for asking, Hans! The example from Tommy Svensson describes exactly the workflow we need. We don't need any visualization which could be annoying. Of course it can be a good help. We would prefer "Shortest path lines with transparent lines" :)

Hans Dahlström: look what Wrike did for the timeline view…!!! Just copy paste! It’s beautiful!

Tommy Svensson: No, we dont do Gantt scheduling (daily planning with end to start 'automatic' pushing) at Favro since it creates much more problems than it solves. Dependencies should be used with cautation. Favro is designed with an agile mindset in mind, for those who prefer non agile tools, there are older and more fitting tools than Favro.

Hans Dahlström: Ok wow... that is REALLY counter-intuitive and business wise a wrong decision I think. The idea is to bridge non-agile ppl over to an agile toolset in Favro. For that to happen, thresholds need to be lowered.

Having introduced start and end times already in Favro, you've clearly embraced the idea of allowing some means of scheduling/planning. In fact, such properties are a must regardless of methodology. Allowing users a nice way to plan does in no way prevent users from being agile further down in the process. I mean, why not allow for automatic pushing of dependant tasks...? It's a feature that saves a lot of administration time. I see Wrike's solution simply as a way to put more powerful tools in the hands of the users. Whether the user resorts to waterfall principles or not, that must be up to her.

To me, saying "we don't do Gantt scheduling" is confusing. Why then not remove start and end times altogether?

We must not forget that 99% of people think linearly when it comes to task prioritisation. This applies to timing as well. If start and end times exist in Favro as a property of a task/card/epic/whatever, then surely all accompanying properties and features should come with it. Otherwise you end up with only half a product.

Don't get me wrong, Favro rocks the world so far, but it can always be improved in order to accommodate even more users in the space.

Could you elaborate on the problems that emerge from having automatic pushing of dependency cards?