The ATMAN Blog

Now, a question for you guys. What - if anything - is wrong with the user stories below? Check out the context from a previous blog post.

1. [Add parent] As a product owner (PO), I want to be able to add one or more URL-pointers (*) to a backlog item in the Edit tab so that I can denote its children.
2. [Add children] As a PO, I want to be able to add a single URL-pointer to a backlog item or a sprint goal in the Edit tab so that I can denote its parent item.
3. [Add reciprocal relationships] As an Agilefant user, I want that when parent or child relationships are added, the respective reciprocal relationship(s) are created as well so that I don’t have to go and add them separately.
4. [Create child] As an Agilefant user, I want to be able to create a new child for a backlog item (that inherits all the relevant properties of the parent, such as themes) directly from the parent item’s edit tab so that I don’t have to go copy-pasting the parent’s URL pointer and remembering its various properties. For the same reasons, I want to be able to transform a ‘todo’ to a child item from the Progress tab.
5. [Show child progress] As a PO, I want that the status of child items shown in parent items like todos are so that I can evaluate the progress of the parent item (it is possible for an item to have both todos and children; progress of grandchildren or child’s todos do not have to be shown in any way)
6. [Navigate hierarchy from list] As an Agilefant user, I want to be able to navigate to an item’s parent or children directly from backlog item listings (such as daily work, product, project, iteration) without opening the item in question so that it is feasible for me to study the hierarchy.
7. [View relatives from list] As an Agilefant user, I want to be able to see the names of the parent and child items of a backlog item directly from backlog item listings (such as daily work, product, project, iteration) so that it is feasible for me to study the hierarchy.
8. [Create sibling] As an Agilefant user, I want to be able to create a sibling for a backlog item (that inherits all the relevant properties, such as parent, themes, iteration goal, etc.) from the backlog item’s edit tab. Likewise, I want to be able to transform ‘todo’s into siblings from the Progress tab
9. [Navigate hierarchy from edit tab] As an Agilefant user, I want to be able to navigate to an object’s parent or children from the Edit tab so that it is feasible for me to study the hierarchy.
10. [Mass change parent] As an Agilefant user, I want to be able to denote the parent item for several backlog items in a single operation (”mass change parent”) to ease the transition to hierarchical backlog items

Those giving the best answers will be awarded with Agilefant merchandise! :-)

In my last ATMAN Blog post I wrote that splitting backlog items directly into tasks is not a good idea and that all backlog items selected into an iteration should be taken into account when creating tasks. I was wrong.

After listening Kristian Rautiainen give a lecture on agile project management I came to realize that just considering the backlog items selected to be realized in the iteration is not enough. When tasks are created, everything that affects the implementation of the software source code must be taken into account. In a multi team environment this includes technical dependencies between teams. Although some agilists are against such planning, the backlog items that are very likely to be included in the next few iterations should also be taken into consideration. Emergent architecture simply doesn’t work in any non-trivial software and building the right amount of modularity in the first place will save some refactoring work later.

Mike Cohn just blogged on one piece flow.

“…So, while I think swarming in this way is an excellent technique to use sometimes, I don’t think it should be the default way of working for very many teams. Some may benefit from it over the long term, but most will find that it introduces too many opportunities to be in someone else’s way as they try to make progress. I consider it equivalent to a drill that a team may do to improve a skill–good to use for practice but not the way to do something forever.”

Check the entire  entry and the discussion that follows.

Here are a bunch of stories for Testarossa’s upcoming sprints. These already add a lot of value and I’d consider it a success if Testarossa would deliver them.

I’ve put in quite a bit of implementation-related detail to demonstrate how little must be changed in terms of Agilefant’s user interface.

Listed in relative order of importance (subject to change, however):

1. [Add parent] As a product owner (PO), I want to be able to add one or more URL-pointers (*) to a backlog item in the Edit tab so that I can denote its children.
2. [Add children] As a PO, I want to be able to add a single URL-pointer to a backlog item or a sprint goal in the Edit tab so that I can denote its parent item.
3. [Add reciprocal relationships] As an Agilefant user, I want that when parent or child relationships are added, the respective reciprocal relationship(s) are created as well so that I don’t have to go and add them separately.
4. [Create child] As an Agilefant user, I want to be able to create a new child for a backlog item (that inherits all the relevant properties of the parent, such as themes) directly from the parent item’s edit tab so that I don’t have to go copy-pasting the parent’s URL pointer and remembering its various properties. For the same reasons, I want to be able to transform a ‘todo’ to a child item from the Progress tab.
5. [Show child progress] As a PO, I want that the status of child items shown in parent items like todos are so that I can evaluate the progress of the parent item (it is possible for an item to have both todos and children; progress of grandchildren or child’s todos do not have to be shown in any way)
6. [Navigate hierarchy from list] As an Agilefant user, I want to be able to navigate to an item’s parent or children directly from backlog item listings (such as daily work, product, project, iteration) without opening the item in question so that it is feasible for me to study the hierarchy.
7. [View relatives from list] As an Agilefant user, I want to be able to see the names of the parent and child items of a backlog item directly from backlog item listings (such as daily work, product, project, iteration) so that it is feasible for me to study the hierarchy.
8. [Create sibling] As an Agilefant user, I want to be able to create a sibling for a backlog item (that inherits all the relevant properties, such as parent, themes, iteration goal, etc.) from the backlog item’s edit tab. Likewise, I want to be able to transform ‘todo’s into siblings from the Progress tab
9. [Navigate hierarchy from edit tab] As an Agilefant user, I want to be able to navigate to an object’s parent or children from the Edit tab so that it is feasible for me to study the hierarchy.
10. [Mass change parent] As an Agilefant user, I want to be able to denote the parent item for several backlog items in a single operation (”mass change parent”) to ease the transition to hierarchical backlog items

(*) Pasi has already implemented backlog item/sprint goal/theme -URL-pointers in a branch.

There’s also lots of unresolved issues. For example:

• How should effort estimates work? For now, let’s leave them untouched.
• Should moving / prioritising parents move / prioritise children as well? For now, let’s leave that out as well…
• Should children who reside in the same backlog as their parents be shown as separate items or “be hidden” somehow? For now, no hiding, treat as separate items.
• …

However, I think the steps above are where we should start from. There’s the specs, now start coding! :-)

Our Big List of tools for project, backlog and development portfolio management on Agilefant’s Related work page contains currently over 150 tools, and may just be the most comprehensive listing on the Internet.

It is now also freely editable by anyone who’s interested!

If you have evaluated some of the tools and know of their pricing - as we know you do, please update this info to the list for everyone’s benefit.

If you are a tool vendor or developer yourself, you can also add your own solution and/or update its info!

Today while updating the Related work section and the Big List and  at Agilefant.org, I stumbled across a solution called Project.net.

Seems a quite (typical) ERP-like take on project and portfolio management - complete with servicing & training & stuff - but the surprise was that it was open source!

So, in my eyes, it has potential for greatness - and certainly something I might recommend. We’ll get back to you once we’ve more thoroughly checked it out to tell you what we saw.

There seems to be widespread confusion on how tasks should be created in iteration planning and what is the role of backlog items (or user stories, requirements, etc…) related to the tasks. Many texts that give iteration planning guidance instruct to split the backlog items selected for implementation in the iteration into task. Some backlog management tools are implemented in this way. I believe that this is one major source of architectural problems in agile development.

Backlog items (or user stories, requirements, etc…) should describe a need from the business point of view, e.g. something the customer needs to do with the software or something the software needs to have for marketing reasons.

Tasks describe something that needs to be done from the software development point of view. That is, something that needs to be implemented in the software’s source code.

The relationship between these two different pieces of work that describe what needs to be done is best described as many-to-many. The realization of a backlog item usually requires the completion of several tasks, and one task can contribute to many backlog items (cross-cutting tasks). The figure below shows a simplified example:

Usually there are many more cross cutting tasks in any non-trivial iteration and the tasks shown in the figure are probably too large (or unspecific) to be ready for implementation.

There are two ways to take the many-to-many relationship into account when creating tasks. The first (less recommended) way is to split each backlog item individually into tasks. After all backlog items have been split the resulting tasks are reviewed for overlapping tasks, which are then combined into cross-cutting tasks. The danger here is that omitting overlapping tasks is quite easy as only one backlog item is considered when the description of a task is written.

The second, recommended, way to create tasks is to consider the backlog items as a whole when the tasks are created. Some agilists advocate that the connection between tasks and backlog items is completely unnecessary. As I believe in traceability and preserving the big picture, I think the many-to-many relationship is a better solution. No tool known to me currently directly supports such functionality, but I will be advocating it’s implementation into Agilefant in some form.

Just finished listening to a podcast describing leanish, one-piece-flow-kinda ideas on planning and estimating:

http://agiletoolkit.libsyn.com/index.php?post_id=400364#

The highest value BLI in Agilefant’s backlog may just be ‘hierarchical backlog items’. Based on the ideas described in the first half of the podcast, it could be a sensible thing to focus our efforts on designing & implementing Hierarchical BLIs piece-by-piece, starting immediately.

Or what do you think? :-)

Anni Peura from Helsinki University has finished her Ph.D. on the dissertation process. Here’s an excerpt from the abstract. Bold text by me

The picture that emerged from these various life-stories demonstrated that
there was no ivory tower where doctoral candidates live an isolated existence. Everyday cares in ordinary life and tasks in academic life are both demanding and rewarding at the same time. The main point is that the academic community in general and PhD supervisors in particular should concentrate not only on the thesis-writing process their students but also on the doctoral students´ wider life
situation. Doctoral students need scientific, financial, and mental support. Somebody
must be available to inspire and offer encouragement otherwise the process will
be disturbed. The successful completion of the PhD ritual gives the PhD graduate
self-confi dence and respect but its’ influence on the doctors’ subsequent academic
career is diverse.

The entire dissertation PDF can be downloaded from

https://oa.doria.fi/handle/10024/42487

An excerpt regarding agile methods from Ian Gordon’s humoristic take on various things Quoted from the Oct 2008 issue of Computer. Enjoy!

An Agile Rescue

The software process movement posed a much more serious threat.
It forced a bunch of business-savvy real programmers (fueled by the
fine food and alcoholic excesses of OOPSLA meetings in their halcyon
days) to devise a devious new strategy. They rightly decided that they
must remain true to their “real programmers write code, not documentation”
ethos while finding a way to portray this as desirable to management and business groups, who were increasingly listening to the scary software process propaganda.

This thinking led to the birth of agile methods, an inspired moniker that allowed real programmers to justify their code-only writing desires to the people with the purse strings. I suspect many real programmers were staggered that management bought their agile methods story with such little resistance. But given that agile methods simply let hem continue their time-honored “writing code all night two days before a deadline” ways, everyone as delighted. The deadlines were simply more frequent—not really a oncern for the average nocturnal real programmer.

The rampant success of agile methods—or extreme programming, as a group of constantly caffeinated eal programmers unwisely named it—caused uncharacteristic behavior in some real programming practitioners. They started banding together and forming consulting
companies based solely on promoting gile development practices. It was almost as if the huge burden of shrouding real programming practices in years of secrecy had been
lifted by the acceptance of agile methods. They were now ready
to emerge from the closet, tell the world about how they really wrote
software, and display their fashion violations with pride.

Company names like “GeekWerks” suddenly entered the vocabulary of traditionally quicheeating conservative big businesses like financial institutions and government
organizations. So-called GeekWerkers, often failing abysmally to blend into the prevailing fashions of traditional corporate culture, wandered the corridors of Fortune 500 organizations. They sold their services based on the premise that because their customers didn’t know what they wanted, there was no point spending money writing a specification
and figuring it out. Instead, customer representatives and real programmers should sit around, drink espresso, eat chocolate-chip muffins, and write a few ideas for desirable system features on index cards. When the coffee and muffins ran out, it would be time to send the real programmers away for two weeks to creatively throw together some code that would supply, more or less, the features captured on the index cards. Two weeks later, the customer gave feedback on the implementation, the espresso and muffins arrived, and the next two-week cycle began. I suspect this approach works mainly because everyone prefers muffins and espresso to writing specifications.