@Ben SmithartI completely understand the need for adding new features and workflows. However, they need to be clearly identified. Workflow of today can't simply be called as a "Legacy" workflow tomorrow. And buried under some other view.
You guys are making too many UX changes in a short period of time, which are resulting into more confusion than anything.
Atlassian Team members are employees working across the company in a wide variety of roles.
September 12, 2018 edited
@Zile Rehman we've got an incredibly broad user base with very different needs. The new project experience does already satisfy a large number of users and we will continue to layer on power to continually increase this number. Where we can do better is helping each user determine up front whether this project experience is going to satisfy their needs.
For the UX changes, we've had some hard learnings about how we're attempting to improve how users can organise and find their work. It's great for you to voice your opinion on this and I can assure you we are listening.
I'm looking on how to add hours in sprint that if the task drag into complete section and log down how many hours spend on it, i only find add time in the setting.
Being able to clear the Done pile is absolutely critical. Our team tends to work on 1 week sprints but we have Disaster Management projects that are run on daily sprints. We need to be able to clear the Done buckets quickly at times.
Looking forward to this, overall the Agility Projects are great (remind me of Trello:-)
Atlassian Team members are employees working across the company in a wide variety of roles.
September 16, 2018 edited
Thanks @[deleted]. We'll be looking at sub-tasks as the next piece of work and board clearing will likely be next up after that. The next iteration will look to give users the ability to clear issues ad-hoc, on top of the two week clearing right now. Hopefully the inconvenience in the meantime isn't too frustrating and it's great to hear you are enjoying the new experience overall.
Atlassian Team members are employees working across the company in a wide variety of roles.
September 16, 2018 edited
@Andrew lau We are building out a new project experience in Jira Software and adding features as they are ready. Time logging and reporting as a capability is not something we are currently working on (although it will be in the future). One option is to move your issues to a classic project where you will have this capability, and another option is to use a custom Time field on an issue in the current project. We're currently working on extending the "Update an issue field" rule to add custom fields which will make it possible to log time as the issue is being transitioned to Done. I hope this helps and let me know if you have any further questions.
@Eoin Ryan - I know the user base is big and broad but to clarify two things that block us from adoption (and we can wait for the rest):
Clearing out the Done column - can be manual (a la closing a sprint) or automatic every X days. Just need more than fortnightly.
Group By fields, ideally including custom fields. For instance we work a lot with Cameras. Group by Camera is essential for us. Lots of other things we would like (group by date, etc.) but the grouping by all fields and Custom fields is rough.
Otherwise the team loves the simplicity. Sure, we'd like Epics. Yes, filtering on things beyond labels would be nice. But with the two items above we have our Trello replacement:-)
The Feedback button on the left of my Roadmap view in my new Agility project doesn't react when I click it.
What I wanted to request is... a duration display inside the epic bar as you stretch it (xx days). When we plan, it is based on effort, not end date. The end date is derived from the estimate. So... we'll know how big the release is (xx days) before we know where it should be planted on the calendar.
Atlassian Team members are employees working across the company in a wide variety of roles.
September 18, 2018 edited
Thanks for your feedback @Michael Wilkes - really appreciate it. We'll take this on board.
We'd love to know more about your first impressions on using the roadmap. Would you be open to chatting with us in more detail about your experience? Please reach out to bdavies@atlassian.com if so.
I had a list of done issues in my backlog that I intended to keep and as of today they have disappeared. Is there a default place where they go? can I get them back? how can I keep (store) my done issues for historical purposes?
Atlassian Team members are employees working across the company in a wide variety of roles.
September 20, 2018 edited
Hi @FabioCalo, the issues would have been cleared from the last column on your board after 2 weeks of being there. We do this to reduce clutter on the board. We will look to iterate on how this works in the future.
These issues still exist and can be viewed by Clicking on the "Looking for older issues" link at the bottom of the Done column, or by searching using a filter. Let me know if you are having trouble finding the link. Hope this helps.
Atlassian Team members are employees working across the company in a wide variety of roles.
September 20, 2018 edited
Awesome @[deleted]! Great feedback. The next iteration of board clearing will give you what you need, and we'll factor to your feedback in for when we look at extending the grouping feature.
Atlassian Team members are employees working across the company in a wide variety of roles.
September 21, 2018 edited
Thanks for the feedback @Andrew Rakicsany. We definitely don't want to set the expectation that you are beta testing. We are however rolling out features (that you may know if you are an existing Jira user) as we have them ready to increase the power of the project experience over time. What we haven't done well at is making it clear to users up front what is and isn't available in the new project experience . We're currently working on improving this and we should be rolling out these improvements in the coming weeks.
I believe you've got something on your hands which might become amazing BUT there is a clear lack of customisation for Agility templates which is odd, considering it should be by nature the one to offer the most flexibility unlike Scrum or Kanban.
What would be fantastic is that we can add custom fields to the main issue view, not the sidebar like it's currently the case. E.g. Let's say I want to have a text area for a specific purposes in the main sidebar, left one, of the story.
Estimates with options to have both story and hourly are a definite must. Also, please please please include some simple time tracking / work log feature:
- Log your time
- Compare against estimated
- See variance
- Export to CSV if needed
Just a tiny bit more flexibility on this would go a long way. Also, off topic, why do I have to go to last page to see latest comment here? would it not make sense to have latest answer on page 1 at the top?
LOVE the direction this board is going in. At the same time and in my opinion, this board serves no purpose if you cannot release tasks... What are we supposed to do when a task gets to done? The "Done" column is going to be a beast.
Atlassian Team members are employees working across the company in a wide variety of roles.
September 25, 2018 edited
@Clark Taylor the Done column issues are cleared off the board after 14 days. The column will then show a link to find them using the search page. However we know this is not ideal and we are working on designing a better way to clear issues off the board. Let us know what would you expect a feature like this to do. You can post here or use the feedback button on your board.
In my company we are faced with the following issues:
Our Projects can consist of multiple epics, and epics could potentially contain sub epics (with stories in them).
We give stories points, and track the time spent on the stories. However, for projects, our CEO's are interested in understanding the total expected man hours duration based on our backlog. (so they know the costs) It would be nice to see reports of average hours spent per point (for a team, or even for a dev). (Your sprint velocity report is ok, but of course the expected and actual velocity alters based on peoples sickness and holidays etc. Ideally, i'd also like to be able to easily identify the stories in sprints that bucked the norm (ie took wildly longer or shorter than the norm). That way the team can try and learn from them.
@Keith_Pillar Never heard of sub-epics in any agile framework that I came across. Isn't story enough to divide the epics, why the middleman?
What your CEO seems to expect is pretty much "how much and when" which smells like waterfall to me.
Re average hours spent per point, I think in planning it works vice-versa, where most people do a bit of mental math and map certain story point to time estimate. For example 1 story point = 1h of work for the sake of argument.
Problem is that by definition you don't care about hours or man days when working with story points, you care about completed set of points so you can anticipate how much work can be done in future period. Since story points are relative sizes.
I might be wrong but using story points and hours against it like you described makes very little sense. Simply make people use original time estimate instead of points, if points are not used even correctly as seems to be the case.
@Srdjan Colak I'll try and answer your observations: The project may be to deliver a car.
An epic may be to deliver transmission
a sub epic may be to deliver drive shaft
another sub epic may be to deliver gears. For each of these epics there may be multiple stories needed in order to deliver.
I guess i can see the ceo's perspective. All our ceo is saying is give me an indicative price before i decide to spend the money on the project. When you goto the dentist he gives you price for doing a filling, he doesn't say i'll let you know cost after i finish.
We dont get our people to estimate the time for a story as they can get this wildly wrong. We get them to estimate points, and keep sizing relative to other stories they have completed, and we also ask them to keep track of time spent on stories. Using points to estimate how much work will be completed in future period is open to errors. If half the team get sidelined for illness or holiday, the points estimate for predicted velocity will be wrong. Whereas, if i can look on a sprint by sprint basis and chart the actual hours spent per point delivered, i will get a truer gauge of what the team are actually delivering. It may well be that certain (more complex than originally estimated) stories result in less points per hour. As such, we can use the metric to help inform us that stories fall outside of the norm.
Ideally, I want to be able to estimate with some degree of confidence-
this epic is complex and carries a risk of scope change due to things we learn during development, and based on 50 story points and our current team we anticipate it will take 300 man hours to complete.
this epic is clearly defined and has little risk of scope change throughout, and based on 50 story points and our current team we anticipate it will take 100 man hours to complete.
Hope this gives you more info on where we'd like to get to.
@cy I'm sorry no one answered your specific question before now.
Structure Cloud will be available later this year. If you are interested in joining the early access program, or the mailing list so you hear updates when we have them, visit this link.
402 comments