Visual Aid.

When I am writing User Stories and Acceptance Criteria, sometimes I really do wonder how my poor developer teammate is supposed to understand the garbled descriptions and instructions I put together. Sure, sometimes it so obvious, there is no danger of mis-communication, but more often than not, my stories are complex and complicated and convoluted.

Personally, I am a big fan of visual representation of what I would like to achieve. Actually, truth be told, I almost always draw a plan or flowchart of whatever it is I need to then put in writing. Not sure why, but when I can follow the flow of an arrow, I’m much more likely to find gaps in my thoughts, than trying to read through a script. Likewise, when trying to imagine changes in our UI, I prefer to create a few mockups instead of writing descriptions.

The downside for me is, that it usually takes longer to create a mockup or flowchart. Simply writing down what I want is absolutely quicker, but then again, more often than not, writing doesn’t accurately convey what I was trying to explain, so I end up having to go back and forth to explain anyway. After all, there must be a reason people say a “picture is worth a thousand words”.

Naturally, it usually pays to not rely only on my drawings or scribbles and I pretty much always write up everything, but I absolutely think that nothing beats a good visual aid.

 

The post Visual Aid first appeared on Agile, Now What?

Advertisements

Backlog Button.

I have spent so much time over the past few weeks reading, updating and prioritizing items on our product backlog, I feel like we could have literally built a whole other system at the end of it…

I exaggerate of course. The list is not that long, but it certainly felt like it at the time. It can be so time consuming when not enough care is taken to write down the requirements or problem steps in the beginning. Trying to decipher somebody else’s description of an item really is challenging, it almost seems like  some of them are written in a foreign language. I mean, I know we have users in China, but i’m not sure that means that our backlog has to be written in what appears to be Chinese?!

Nevertheless, there’s only one way to deal with this and that is grit your teeth and fight through it. Unfortunately, diligently updating and prioritizing the backlog really does take time, far longer than I ever thought possible… and of course, nobody wants to wait until we have checked everything before choosing what we will work on next. Surely we already know what the biggest priority items are anyway, right?

Well, truth be told, at this point in the game, we don’t. By “we” I speak of our collective Product Owner team. Of course we each have our own opinion as to what we would like to get done first in the next release, but a clear and definite answer to what is the next big thing? No, I can’t honestly say that we have that. Not yet anyway. We have a good idea, we have a strategy and a plan to get there. What we don’t seem to have is enough time to actually do it.  And I really really wish we did, because it is more than a little demoralizing to have to say that no, the list is not ready yet. Especially when most people seems to think that the one (and only) thing we POs are responsible for is that very same list.

After all that the top priority item on my new list will be this: a Backlog Button! 🙂