So we all use some kind of ticket system like JIRA or on Azure. I’m interested in the columns and perhaps rows your have on that board. Perhaps even custom fields or tags you use in order to make your process flow better.
Clients have always struggled to create the perfect board for everyone.
I’ve seen boards like:
ToDo, Doing, Done
And it’s for Analysts, Developers, Testers and Business.
I’ve seen boards like:
To analyse, analyzing, ready for dev, developing, code review, …
Which makes the board insanely large.
I’ve seen boards like:
Analyse, Develop, Test, UAT, Done
And they use custom fields to work with different states and if somebody is assigned or not …
As you can see it can get messy.
I’m interested in learning new ways of creating boards and processes.
So please share some ideas!
I’m specifically looking for ideas to make testers work more visible. I’m not looking for too many columns since the teams often don’t like this. But when developers have a “todo, doing, review, done” I can’t seem to stop thinking, testing is just the same for us and why don’t we have those columns? Then again analyst also!
We use subtasks and by that don’t need a test or ready-for-test column (my arguments against such a column). Much work can be done in parallel and different columns keep you sequential order.
Also by subtasks multiple people working on a ticket could be made for visible easily.
In to Open, In Progress and Done we also have Review column, because it helps the developers. I put sometimes my test tasks into that column, when I want a debrief.
I still find I hard to display the testing work in that column and would prefer another way.
As I work in a Scrum team I create the following subtasks per story:
Create Testplan (often): it’s about gathering information in advance, discussing the risks and focus of testing of the feature within the team. I do this on a dedicated Confluence page as Jira can not handle parallel editing is descriptions (last one saving overwrites other changes). I create the subtask often, but not always (but always the page for stories). Some tickets are too small, the gathering is done in 5 minutes.
Testing (always): exploring the product and reporting about it to people who matter. Sometimes it’s just one, sometimes multiple with different focus (e.g. Test X, Test Y). These subtasks are seldom limited to one day, but last multiple.
Like hinted, the details of my testing are stored on a confluence page. The board gives just an overview, showing the general topics I’m on.
Because of that it’s even more important to tell the team something about the progress in the daily.
If I had the choice a would show the Confluence page to talk a bit more detailed about the testing. But I’m the single tester and our daily lasts sometime longer, even without me doing this.
I think for showing progress of testing would be Session-Based Test Management a good thing. You can create sessions as subtasks in advance and on the run. As each sessions should just last some hours, subtasks move every day.
I didn’t do that so far.
I see, I’m going to make the assumption you are using JIRA?
Here in Belgium we basically moved on to Azure, all my project in the last 7 years have been basically Azure and they still struggle with showing subtasks on some boards and if they are on the board I just fear that subtasks might clutter the board, if there are too many.
I’m also pro subtasks don’t get me wrong, it’s probably still the best way!
If you had all the time and money in the world, how would you display it?
How would the product owner or a test lead with 1 view see how much test work is done and still left for his user stories for this sprint?
Yes, Jira.
I’m sad to hear that about Azure.
I can give you tomorrow a screenshot of our board. Or works for us.
I don’t have a test lead.
When they look at Confluence page. But don’t forget that this is just an artifact. Talking with people and the progress and state is important.
Also my PO trusts me and don’t wants to know every details. When he ask me in that direction in the daily I take the time to explain it to him after the daily.
And this is just a simplified explanation of what I do. It’s hard to write and details.
Trust it’s important.
It’s more a matter of time and mindset then technology. For me is the Confluence page sufficient (a Miro board with the possibility for mind maps would be even better).
While it has some advantages of being a tester in a Scrum team (sadly the only one), I’m missing having a good test lead which has some authority. Despite that things have improved, testing is still often second in line. Developers are still developers.
Also I find the Scrum Daily not the right slot to talk about testing in detail. It would need another meeting for that.
While writing this lines I realized, that I don’t need to show more on the board as long as people trust me.
Having more interest and appreciation for testing would be nice.
And I don’t think that a board is the right place to show the state of testing in detail. My preferred format is a mind map.
How is your setup? How is the team working?
What I describe works for in Scrum team. We don’t have analysts. Aside bugs, anything we do in our sprint is was in Refinement meetings upfront. And it’s discussed one last time in the Planning.
One more thing on that: more important, and also harder to change, would be for me to have a more flexibel board then the one from Jira. It is limited compared to a physical ones.
An alternative would be with Miro. There is it possible to have boards, which offer the freedom of physical ones. And they can be connected to Jira for using the tickets from there.
One limitation of Jira: only one assignee per ticket (no matter the type).
In Miro you can place multiple avatars on tickets, like in real life.
Subtasks fix that just partly and we don’t work always with subtasks (I would prefer that). Still I prefer to have them for other reasons.
Also Jira boards can’t show further information easily like planned release dates. Would be cool to have note with that present on the board.
I’m not asking for any specific team, just asking in general but 99% of my teams were: Analysts, UX Designers, Developers, Architects, Testers and then PO and sometimes a PM.
I see my advice specific for more agile ways of working. Especial Scrum, haven’t done Kanban so far. If you have a certain waterfall’ish workflow you have to follow, then it might not be that applicable.
I haven’t worked in the last decade in companies with analysts, but they most times used Scrum. Therefore I have no idea how they are integrated.
I GUESS that most of their work should be finished before the Scrum planning. Because requirements should be clear before the team starts working on them.
But that is me. Maybe others have other perspectives on that.
hm … maybe when I would be forced to have Analyse column, I would prefer to have Development and Test into one and using sub tasks.
It makes no sense to me to wait for anything I could do upfront until developers are fully done with coding and building. Creating a test plan from the requirements, preparing data, improving a tool to fit eventual new needs of the story etc.
Yea they mainly work towards the next sprint goal but those are mainly not in the sprint
An example:
If a ticket is returned to an analyst for further clarification, it’s assigned to him but we can’t have it “in development” since it’s not “in development” no more
That’s what usually happens.
But … could not theoretically the people work on other parts of the ticket (most times)?
Sounds like sub tasks would be good.
And/or in general refinements with the whole team would make way more sense. Having most clarifications with the team upfront.
Hell of waterfall and single assignees on tickets.
Individuals and interactions over processes and tools.
Ive had boards that had:
To Do | Doing |Done
and
Experiment| Interesting | Oops
But if people are really serious about it, then the columns could be named after their practices.
E.g. instead of in progress it’d be “TDD” followed by “Product Behaviour Exploration (PBE)” followed by “Deploying” which then automatically moves to “Deployed” or even “Launched” followed by “Operating” (as it’s never done…am I RIGHT?)
Someone asked me about the related DoD in relation to the boards, this was my response with personal opinions to someone who knows me.
Multiple discussions and options on this, important thing is the team is aligned on the understanding. They range from
1. Developer has finished coding - not even in dev yet. This one is useless. 2. Developer coded and feature in build ready for testing. Has its use. 3. Developer coded and dev automated tests run successfully. Higher value. 4. Developed, automated test in place and verified by tester. 5. Developed, automated test, verified and testing explored. i.e Done means its fairly safe to go to production - often common understanding of done. Advanced usage but makes a lot of sense.
Example: in one project we are using 2. This works in this case as early dev cycle with nothing planned on going to production for months.
We have a separate test board which would normally be something I argue against as extra layer but in this case it works well, its a subset of tickets.
They have a lot of tickets, some are small technical things, others on their own are not ready for testing in isolation so if tickets remained undone as not explored the board would get cluttered and each sprint would contain loads of things from prior sprint, alongside this are 3rd party elements off main board.
By using 2 this allows us to clear dev board each sprint even on smaller tasks that are still pending testing. The addition of test board makes sense as it still allows testers full visibility on what’s ready for test and can manage and prioritise testing accordingly. Simple ready for testing - tested.
Importantly we discussed DoD and the board in depth with the team to establish what worked well for all parties, this bit should happen on every project.
Now no doubt some will spot some other issues in the above approach, to be clear it worked well for us, it may not work well for others. I’m throwing in here because the separate test board element is unusual and we found it of value which surprised me a little.
the most complex I’ve seen was:
To-do, In-progress, Deployed dev, Deployed Staging, Deployed Pre-production, Deployed Production, Done.
What each of them means? That would be shared understanding within the team.
Did all of this make sense? Absolutely not
Currently we follow To-Do, In Progress (which is mapped to Development, Ready for testing, testing, Ready for Prod) and Done.
So the main 3 are columns you can say.
I find less columns to be better but it all boils down to individuals keeping their nit picking aside and agreeing on the usage.
If the team is consistent in upholding the process i.e. regularly updating the board, it will work no matter what the config.
Ready for Analysis
In Analysis
Ready for Refinement
Ready for Development
In Development
Code Review
Ready for Deploy to Dev
In Dev Testing
Ready for Deploy to TST
Ready For Testing
In Testing
Ready for Deploy to UAT
Ready for UAT
In UAT
Ready for Deploy to PROD
Released
Cancelled
All those are columns but if I were the tester I would only see my board:
Ready for Deploy to TST (to see whats upcoming)
Ready For Testing
In Testing
Ready for Deploy to UAT
So in total I would have 4 columns but only for me
If I wanted to see the “full board” I would use a different view.
Which is what the PO used.
if someone asked the PO “can you tell me what’s going on in this sprint?” and the PO is unable to write a few lines of where each topic stands, then those columns need rethinking
Well to be honest, it worked absolutely great.
The PO never had to come and ask us what the status of the sprint was after we did this. Everybody had his own board with their own ToDo’s.
Everything was always superclear, we had a dashboard to see if there were items for the next refinement, we could review them beforehand etc…
Probably the best project I ever had (in matter of way of working with tickets)
Some teams need different workflows, and when a workflow has many steps we merge those steps into one column on the board, which hides information. It all boils down to #Definition-Of-Done quite often for me.
And then, @sebastian_solidwork is reminding us of how much more important it is to just find defects and verify the fixes, than it is to argue over how many columns your board has, or whether Jira is a dirty word in your company. #BikeShedding. The real money is in having a manager who worries about that kind of thing and who forces engineers to write better ticket titles and better ticket definitions of done. Period.
I have the same pain @kristof has, two of our teams, by necessity, have such a different workflow that people forget what each ticket state means. It often feels like getting teams to work together is better served by duplicating and “linking” tickets across projects, to make this easier to track on everyone’s board when a ticket needs to move from one team over to another - but that kinda brings me to a discussion as to who is your customer when you do an internal delivery. Once again a #BikeShedding danger area.
For me, less columns wins every time, and better ticket descriptions that remove implicit knowledge.
?)
