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?

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! 🙂

Do’s and Don’t’s

Super busy today! Somehow I couldn’t fit writing a full blown post into my schedule today, so instead here are some thoughts from another bright mind:

What we don’t do. by Clarke Ching from Clark Ching’s Rocks and Snowballs

A great little piece about whether we can really appreciate what we gained by eliminating non value adding tasks and processes through agile.

How can we celebrate something that what we don’t do?

Choosing Change.

Something I find particularly difficult to deal with sometimes is how to handle all the suggestions, ideas and requests we receive from our end users. I am not talking about feedback regarding functionality that we are currently working on and where we specifically asked for feedback and user input. I am talking about all of those little things that users would really really like us to change or add to the application – particularly those that may not necessarily be a good idea.

Of course, users always have a specific reason in mind why they want the system to do something. However, not always are these requests really born from necessity. Especially in our case, where our application is replacing another system that many of our users have been working with for years, in some cases even decades. It’s no surprise really, that a not-insignificant number of enhancement requests could be simplified into one user story:

“As an experienced user, I want the system to handle this process the way my old system did, so that I do not need to change.”

Like I said, nobody is at all surprised that we receive requests like that, however somehow we haven’t yet figured out the best way to deal with them. Yes, we do have an extensive team of trainers, support staff and even a specific change management department, but requests such as these seem to bypass those teams entirely and in the end, tend to end up as enhancement requests in our product backlog.

For us product owners, this makes the process of prioritizing and grooming the backlog that much more difficult, because not only do we need to evaluate, prioritize and write user stories for all the very valid and great suggestions we receive from our users, we now also need to figure out what to do with the undesirable ones, who frankly just clog up our queue.

I do believe that the product team is responsible for choosing change – but we are probably not the right team to manage its undesirable cousins and the users who request them…

Don’t Lose Focus on Collaboration.

I was looking for inspiration for the blog when I stumbled across this post by Satish Thatte on the Agile Management Blog.

Balancing Individual Focused Work with Collaborative Team Work: Open-Office Bullpens are Harmful!

I have always been a believer in making sure that my work is a balance of team-time to catch up on what’s going on and focus-time for the more complex and intricate tasks of my day-to-day. Working remote from my home office, it’s pretty easy for me to make that happen. When I really need to focus, I can just avoid my instant messenger, screen any non-urgent calls and dive into the deep pool of total concentration.

My colleagues who work in our “agile friendly” open plan offices are not so lucky. Yes, agile promotes co-location, but how useful is it really to have non-focused chatter in the background while you work? Let’s be honest, not every conversation that happens in an office is actually productive or even related to the work going on. We all chat with our co-workers about our weekends, where we should go for lunch, and so on… Yes, we also discuss our work, but not all the time is the topic of conversation really worth the interruption of and breaking our concentration.

Therefore I question, are open plan offices really the best layout for productive work?

Happy New Year!

Another year gone by, another set of project milestones achieved, another pile of features, enhancements and bugs evaluated, developed and fixed. If I may say so myself, 2013 was a fantastic year for our project!

We made the switch from waterfall to agile scrum. We became more focused, more transparent, more efficient and effective. We learned new tools, techniques and threw ourselves into the change. We tried, we failed, we tried again, we panicked and cursed, we never gave up – and when we look back now, we succeeded.

We involved more users and subject matter experts than ever before. We designed the software with our users for our users. We delivered high value, high impact solutions and earned great feedback and appreciation in return. Our product has never been better, our process is working and we have an incredibly talented, committed and positive team!

It is now 2014. The (never ending) cycle of software development begins once more. From where I am standing, I can’t wait to jump in! I feel motivated, I feel excited and I feel like I have a brilliant team in my corner itching to make our product even better.

So today, the first post of the New Year, it is all about inspiration, motivation and saying THANK YOU!

You all know who you are, you make our team awesome, you support each other, you work like crazy to deliver and you have fun doing it. Thank you for your hard work, your dedication and your energy.

Here’s to another great year!!

Merry Christmas.

I know it’s not considered politically correct to wish anyone a merry Christmas these days, but I just can’t get used to saying “Happy Holidays”. Although, having said said, I suppose I am always happy about holidays, so perhaps it’s not so bad after all…

Today I am busy getting ready for the aforementioned holiday, making sure everything that needs to be tied up, is tied up. Anything that needs to get done, is done. And everybody who may need me over the next week, knows that it probably ain’t gonna happen. 🙂 …unless of course there happens to be an agile emergency, in which case of course I will move mountains for the team!

Keeping the spirit of this post light, I wanted to share a little Christmas fun I found the other day: Top Ten Gifts For the ScrumMaster In Your Life  by Mike Cohn at Mountain Goat

I’ll be away the next couple of weeks, spending some quality time with my family – I hope you get the chance to do the same!

Have a good one and see you in 2014!

Don’t Get Emotional.

One of my least favorite tasks as a product owner is having to prioritize the backlog and stack rank stories to make sure we develop the right things at the right time. In principle, I don’t have a problem prioritizing items, what I do find rather frustrating is how emotional and subjective prioritization often is.

I myself am a huge fan of logic and formulas and empirical research (geek alert!) to reach a conclusion as to which items are important, rather than just going with my gut. Having said that, sometimes it is necessary to go above and beyond what the data says, because there is a specific item that triggers a lot of emotion – negative or positive – from the overall user community, that warrants an increased priority.

On my project, we have a lot of those very vocal, very passionate users, that are sometimes rather difficult to temporarily drown out, so the product team can objectively assess and prioritize enhancements to our application. Furthermore, a lot of us product owners, myself included, have worked in the field as a user at one point in our careers and therefore still have some emotional ties to what is was like being a user. On top of that, we have spent a lot of time and effort to foster a culture of actively soliciting user feedback and enhancements requests, which makes it very difficult and rather uncomfortable to say no to requests, even though sometimes we probably should.

With all of this emotional baggage, a product owner’s judgement can easily be clouded – not deliberately, but subconsciously. Even more reason to develop a clear-cut, fact-based system to rank and prioritize stories and features based on their attributes. But which attributes are the right ones to look at? Do they all carry the same importance? Do we rank technology over user experience or vice versa? If the system crashes, because we overload it with data and logic, that is obviously very bad. But at the same time, we also cannot ignore the user emotions and aggravations. Instead, we need to find a way to quantify the user reactions to be able to compare and contrast them other measurable aspects of the product. Only then can we determine whether a screaming user is just having a bad day or it is a clear indication that something is very very wrong…

I don’t have all the answers yet, but one thing I am certain of: if you want to improve the prioritization of your backlog, be objective and don’t get emotional!