tagging. themes, qualities and color-properties

Hi there,

Our team unfortunately fills multiple roles. The correct way is possibly to split into multiple projects, but that’s not really appealing.

Due to considerations to stakeholders I would like to hear your comments on the following:

Currently we are using Themes to tag stories relating to each others. But I am not sure if this is the “right” thing to do.
What comes more to mind is “tagging”

Also we currently [mis]use Qualities as a form of tagging for an entirely other purpose. Our (not so) agile management requests “Visual management” which they interpret as lots of Post-its on a wall.
I have simpy made a shell script extracting the backlog and printing it out using “Qualities” as color tagging (Bwaaadr”) sry.

So my questions are:
1. Are we using “Themes” correctly in this matter
2. If not, then should I submit an issue for making “tags” available?
3. Tags with properties (for coloring) perhaps.

Well – what say you?

Status

Issue is closed.

Comments

Mon, Dec 9, 2013, 15:30 by Witek (SM,T)

You described how you (mis-)use qualities, not how you use themes. In Kunagi we implemented themes to group stories. Examples would be "Start-Page" or "Configuration".

Qualities are designed to define reusable quality-criteria (or test-criteria) for stories, so the product owner does not have to type the same quality standards to every story. Example would be "System responds within 300ms" or "Documentation available".

Giving colors to themes makes sense for me and I think it could improve visibility on the product backlog.

Tue, Dec 10, 2013, 09:26 by Karsten Jeppesen

Hi Witek,
Belive me - I am really trying to make this work, but my main issue is that our management is not skilled in working with SCRUM teams, so I am trying to get the teams to work agile while getting upper management to figure out how to work with the teams.
The main complaint from "above" is that it is difficult to relate the sprint goals to the stories at hand. It doesn't help me neither that we are working with two intertwined projects nor that there is a technological debt, manifesting itself as high priority incoming issues coming at a significant rate.

Nevertheless maybe describing my predicaments this way may help:

1) While the PBIs are in the product backlog they are sorted by priority, but once they are in the sprint backlog I need some relation to the sprint goals to satisfy the stakeholders (read project managers). This could be satisfied by sorting the stories in the sprint backlog accordingly to their relations to the sprint goals. It is perfectly ok that this only applies to the public website as I am working heavily to get onlookers out of the private kunagi (the not-velocity) site.
At this point I have no solution or work-around for this problem.

2) Upper management measure productivity in terms of kg-post-its/m2 on billboards. This is causing our POs endless grief. I therefore made some shell scripts which produce yet another website which printed out on a color printer results in a tiled and laned "product backlog" sorted by Product backlog priority vertically and project-wise horizontally (pls stop crying). The different project components have different colors. An example is HW; Controller SW; Target OS; Research.
So the misuse of Qualities happens here.

Mix this with the wish to conform best possibly to Agile and getting general acceptance for Kunagi which I find superior to ex Redmine for its focus on the team and not those trying to micromanage it.

Tue, Dec 10, 2013, 10:53 by Witek (SM,T)

When I understand you correctly, you use qualities for grouping instead of themes because you already use themes for another purpose, right?

What about using themes for both grouping "dimensions"? Just prefix some themes with HW_, SW_,... Your export script or the website could filter and colorize using this theme-prefixes.

Tue, Dec 10, 2013, 12:13 by Karsten Jeppesen

Thanks Witek,
I believe you are right. I will give that a try. But the issue in 1) still remain. I can repeat that in another issue if that's easier for you to handle.
A "few" question then:
The backlog code:
<div class="section">
<a name="productbacklog"></a>
<h2>Product Backlog</h2>
<ul>
#foreach( $story in $productBacklog.stories )
<li><a href="${story.reference}.html" class="reference">$story.reference</a> $story.label</li>
#end
</ul>
<p>There are more story canditates among collected <a href="ideas.html">ideas</a>.</p>
</div>

Where is the definition of the "productBacklog" ?
Where is the definition of the "productBacklog.stories" ?
Where is the definition of the "sprintBacklog" ?
Where is the definition of the "sprintBacklog.release" ?
I suspect the same file, but where?

Thanks Witek :-)

Tue, Dec 10, 2013, 12:54 by artjom (PO,T)

I tried to comment yesterday, but my Internet connection was bad. I would like to point out a few things about Themes and Qualities (as they are supposed to be used), so that you can get a better picture how your usage relates to that.

Qualities are non-functional requirements. They are either implemented through other Stories, or they (cross-)affect a number of other Stories. Implementing a Quality may require the same of similar tasks for every related Story, but they are not implemented by themselves. The need for Qualitites in Kunagi arises, because defining cross-story requirements is difficult without such a tool.

Themes on the other hand are, in fact, tags. We might noch have a fancy widget like people are used to from other tagging communities, but the functionality should be versy similar.In practice, Themes serve two needs: 1) You can group elements that belong to the same idea, feature, or subsystem. Once you define a common tag, other entities from that area will be displaced as related. 2) If you have early Stories that are not yet precise and might have a large scope ("Epics"), you can split them into Stories for implementation. Newly created Stories this way will have a common Theme named after the original Epic.

So, related to your goal, using Themes would be more appropriate.

Sorting Stories by them is, however, another matter entirely. This is a very specific request that even slightly contadicts the original intention of having Stories ordered by their Product Backlog priority. As a result, I'm afraid, this request is not a good fit for Kunagi.

Sat, Dec 21, 2013, 21:19 by artjom (PO,T)

Is this issue solved?

Post a comment



optional
optional