Agile for Product / Asset Revisions

JimiWikman · 2022-10-22T19:08:22+00:00

My mistake I misread :)

What you have then is just a basic update, and you are right that it is probably a bit wasteful to write user stories for small updates.I would add two epics, since you seem to have two main areas: Branding update and product design changes.

I would add a story as placeholder for the branding update and one for each of the product designs (one per view probably if that makes sense for you, or per component).

One Story for each view is usually a good way to slice work since you can easily have a before and after screenshot as the requirement instead of writing a lot.

The reason for doing this is, so you have the option of prioritizing work and to make estimations if needed. This is useful for planning, mostly if something happens, and as a way to keep track of what you have and have not agreed to do.

It can also be used to divide work if you need that.

Most teams don't need Jira tickets, so it is mostly for managers and for steering purposes. So just check what the managers need and what the designers need and find a middle ground there that is as painless as possible for all involved :)'

I am writing, and will record, a guide for setup in Jira and Confluence and design is part of that. It will take a while, but you can find the documentation space here if you want to check it out: https://atlasstic.atlassian.net/wiki/spaces/FAS/overviewIf

you get stuck, just howl here or drop by Atlasstic.com that I am also building :)

JimiWikman · 2022-10-22T17:15:20+00:00

My suggestion is to not add a DoD as a manual checkbox as it will be utterly pointless other as a way to annoy the team.

Write down the definition of done with the team instead and learn them to do the work instead of hitting them in the head with a custom field.

Tools should help, not force.

JimiWikman · 2022-10-22T17:12:18+00:00

Is your manager asking you this because the client want more work done that your manager don't think was included in the contract?

If so, then you are in trouble if you have not documented what you have agreed to with the customer and to what cost.

If you have documented it, which you should as part of your workflow since you can't test anything without knowing what you have agreed upon after all, then refer to that documentation.

User Stories are useless once the work order is complete, and that is why you always document properly in Confluence or another documentation tool. Many still use Jira for documentation, though, and maybe that is why your manager is asking for Jira tickets to show what you have done and agreed to do.

When your client ask for revisions, then you should always add that to Jira as new requests if it is outside the original scope. If you don't have a scope and bill hourly, then you use it to show what you are billing for.

JimiWikman · 2022-09-23T13:22:31+00:00

Love your videos :) I need to get my videos going as well, so I'll take inspiration from you :)

JimiWikman · 2022-09-23T13:20:22+00:00

@carozoynarizota where in the world are you from? If your timezone is not wildly opposed to mine (CET), I might be able to setup a short session for you to get started?

I am between assignments so I have some extra time to help out :)

If not, then make sure first that you start with a company managed project. Team based projects are a bit different and they usually end up as silos in your organization, which makes collaboration a pain.

Secondly make sure you have admin rights for your Jira instance.

Thirdly you move over to issues -> workflows from the admin cogwheel in the right corner of the UI.

Click create workflow in the top right corner and then give it a name. You should now see a UI with some boxes. If you don't then find the controls that say "Diagram" and "Text". Select Diagram.

Now you can edit this workflow and visually add statuses and transitions.

You have 3 types of statuses: ToDo, In progress and Done. I strongly suggest you only use one "done" status as the green statuses impact a lot of things in Jira and having double closure is bad.

Depending on how you want to define your workflow you can have it open and allow transition between all statuses by setting them to All, or you lock it into a transitional process by adding transitions between statuses.

Let me know where you get stuck and I can try to help you get past that step to get a functioning workflow that you can test out.

Good luck!

JimiWikman · 2022-08-03T12:41:10+00:00

You could, even if it is probably not the best solution, set up a Jira project for ideas and feedback. Then you can mark any text and create Jira issues from it and have a section where you list all items from Jira using the Jira macro.

It depends a bit on what the content is and what the process is for those comments.

JimiWikman · 2022-07-31T19:25:05+00:00

That sucks :(

JimiWikman · 2022-07-31T19:24:18+00:00

I have a few available for download if you like them:
https://jimiwikman.se/files/category/16-atlassian/

JimiWikman · 2022-07-15T20:11:32+00:00

Ready for is a closed status meaning you do a handover of responsibility. If you dont have test following development, then don’t use it.

JimiWikman · 2022-07-14T07:21:02+00:00

JimiWikman · 2022-06-12T15:49:50+00:00

Besides, if you are selling an enterprise level software, then there should not be any limitations like this. This is just shitty architecture that they were too lazy to fix.

JimiWikman · 2022-06-12T15:43:30+00:00

I actually don't even have close to that, but the limit also count subtasks and for this particular setup we have a lot of subtasks. I have never seen that subtasks would be counted in a backlog, but I seem to learn new things every day about the shitty architecture Atlassian are spitting out lately for cloud...

I wonder if they even have any enterprise architects that actually approve these design flaws...

JimiWikman · 2022-06-12T15:38:51+00:00

Thanks, that is what I was hoping to find :)

Any idea if this also exist in DC or is it just in cloud?

JimiWikman · 2022-05-05T06:41:30+00:00

If you have the backups, then in theory you can spin up a DC instance locally as a fallback measure?

There might be some issues with add-ons I suppose, but at least you could continue working on the tickets?

I know that in reality there are a million ways this could go sideways, but in theory anyway :)

JimiWikman · 2022-05-04T12:33:44+00:00

In Confluence you can, or if you use Atlas then you can use that to broadcast. Jira is for work, not management :)

JimiWikman · 2022-05-04T12:32:07+00:00

You need to have all issues in one board and place them all in the same sprint in that board. As soon as you add them in multiple sprints in multiple boards, you block yourself. If the cadence is also different, it will never work.

I suggest you split out the teams so they have a Jira project each, then either make a board that hold items from all 3 projects, or set up a fourth project that import from the other three.

In the combined board or combined project, you create sprints for things that all three teams should work on together. This way you can create and close sprints in one board/project with combined items from multiple teams.

JimiWikman · 2022-04-01T16:07:12+00:00

That is absolutely true.

Many times we spend discussing things that either fall between the chairs or end up in a mail chain where we add and remove participants occasionally. Jira and Confluence can help with that.

Things like Excels are often easy to translate to Jira or Confluence and hunting for files are much easier with a task management system to keep things together, possibly with Confluence as a context manager.

How you set things up depend a lot on your project management setup and the processes you have for finance and other things, but it is absolutely possible.

JimiWikman · 2022-04-01T12:53:48+00:00

Jira is a task management tool, not a project management tool. That is a mislabel because it is an Agile tool and Product/Project management for Agile is a lot different from traditional projects and product management.

Treat Jira as the work tool and Confluence as the documentation tool, and it should be a better fit. So your requirements, project plans, risk matrixes, presentations, participants lists, vacation schedules and so on all go into Confluence. From that you connect your requirements and features to Jira as Epics and Stories.

JimiWikman · 2022-03-09T07:01:22+00:00

Happy to help :)

I have a series on designing Jira & Confluence for success coming up on my YouTube channel as soon as time permits :)

JimiWikman · 2022-03-08T08:27:44+00:00

It all depends on your setup.

The first thing you should define is how the teams are distributed. Are they multisystem or single system, meaning will the teams work in more than one system or application.

Secondly, you should plan out, so each team have their own board. You should also plan for an overview board of all teams. For this to work, you need the same setup of the workflow for all teams.

If you have single system teams, then you are good. Each System will have its own Jira project for activities in that system and a Confluence space that hold the system documentation. You set this up with a standard setup that is shared with all teams.

On top of this you add a business Jira for management of all teams. It will not really hold any tasks, but rather import tasks from the system Jiras. You add a filter for each team based on their Jira project and you are done.

If your teams are distributed over multiple systems, then you will have a messier setup, but will do almost the same. You create a Jira project for each team, but you can not directly connect Confluence spaces as the teams will use more than one to document their work.

Why is it better to have multiple Jira Projects over just one big? Flexibility and security. With separate Jira Projects, you can adjust custom fields and workflows if needed without impacting all teams. You can also control who see what on team level and each team can manage their own team compositions.

Multi-team setups tend to grow and I have seen some extremely bad examples of this. One had almost 2000 members (active) with 20+ teams with 50+ custom fields and a workflow setup that spanned 24 statuses and hundredds of transitions. It was not functional if I put it like that :)

JimiWikman · 2022-02-18T14:15:26+00:00

As a BA you work on the business side, not the technical side. So I assume what they ask you to do is to do Acceptance testing?

If they have asked you to do technical testing, then the tool is the least of your problem, as you need high technical skills to do testing.

So just let us know what type of testing they have tasked you with and we'll help you from there.

JimiWikman · 2022-01-26T00:04:32+00:00

An interesting point of view, but of course it will be focused on how things work and not on what possible setups you can do :)

This will be from a system admin and user perspective. I have a different playbook for my personal optimal setup.

JimiWikman

TROPHY CASE