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

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


I was actually very happy this Monday, strange I know, but right now, everything to do with my (part of the) project seems to be going very smoothly. My team is primarily focused on the technical discovery for the next feature, which leaves me with a bit of breathing time to focus on the backlog.

Not that it was easy to get to this point. It took us quite a while to get to a point where everyone was aligned and understood what our next steps should be. Now that we have switched to agile, everyone involved in the process is less and less comfortable with the idea of spending time on anything that may not yield shippable software. Problem is, this next feature we are working on is so complex, involving multiple systems, multiple skill sets and processes that we simply needed the extra time.

We already spent a few weeks digging into and defining the business process – we really needed to also allow the same focus on the technical discovery to make this piece of the puzzle work – and more importantly work well! But, how can we communicate what we need to do, show our progress and make everybody understand the value?

Well, we ended up trying various different approaches and quite frankly, in the end, the most effective way of communication was a checklist, albeit combined with a couple of fancy graphs to make it interesting. Having a clear list of what we needed to do and investigate in order to be able to move forward with this feature was ultimately what we all needed in order to move forward. For our team, it gives us clear direction on what to work on now and next and for our stakeholder outside, it gives them a good idea of exactly what we are going to deliver and when.

Being a big fan of lists – I make lists for everything, literally – it was more of a compulsion to create a list of tasks and I did it primarily for myself to get my head around the process. In the end however, it turned out that it gave us and leadership the direction we really needed to stop talking about how we might do what and just get started and get stuff done. We eventually turned our checklist into stories, so now they live as our spike backlog and we can create the usual burnup charts that show our progress and productivity – making sure our stakeholders are happy  and informed.

So, we are now back in the world of scrum, with backlogs, showcases and burnup charts, but in the beginning, there was my good old friend: the checklist. I couldn’t have done it without you!


Backlog grooming.

Reading about backlog grooming on other blogs and talking to other Product Owners, it seems that backlog grooming takes place primarily within a certain release or even just from sprint to sprint. What I am noticing in our project is that backlog grooming further into the future is proving a little tricky. Especially for all those requirements that we gathered when we were still planning to continue developing in waterfall as opposed to agile.

Those requirements were typically written in a different format and are a lot more specific, as is required in a waterfall project. Now that we have switched to agile, integrating the “old” requirements into our current backlog is not quite as simple as turning them into appropriate user stories.  Most of them have to be rewritten rather than just be updated into user story format, some are better off grouped into one agile epic and some really are just too specific technically, which would stifle the iterative process of agile. Not to mention the huge effort of sifting through the backlog of hundreds of “waterfall” requirements trying to identify those that were either implemented or made redundant by some of our more recent development.

At the moment, since we have switched over to agile earlier this year, I am not sure we have found the most effective way to manage our backlog for the future. Rather than having one source of epics and features that we would like to see implemented at some point, it seems there are various versions of spreadsheets, requirements documents and vision presentations. For the most part, these requirements and features are organised and categorized to make it easy to prioritize them, however that is largely true for the new additions, not necessarily for any of the older “waterfall” items.

I am not personally the keeper of this backlog, so I can’t speak to how easy it is to manage on a daily basis, what I can say is that as an outsider it is difficult to get the big picture. Perhaps compiling all of these into one centralized backlog is the obvious thing to do, but admittedly that may not be as easy as it sounds. While we have implemented and are using online software to manage our sprint and release backlogs, our product backlog still is very much an off-line beast.

Now that we have a couple of agile releases under our belt, perhaps it is time to develop a more transparent backlog process for the future – otherwise we may end up having to spend a lot more time grooming.

Managing Change.

During a recent internal stakeholder meeting, our leadership team brought up the challenge of dealing with changing the working model for a technology project and how we experienced it in our team(s). Since we are (one of) the first teams in our company that have adopted the agile scrum model, it’s often all eyes on us to try and determine whether it is something that should be rolled out to other projects and teams within the company.

While it is easily communicated, documented and supported with facts how working agile has improved out productivity and product quality, it is not so easy to also share the process and the challenge of managing change. Changing from waterfall to agile is not just simply a change in the way we do things day-to-day, more like a huge fundamental upheaval of everything we do and the ways in which we do it.

For myself – and I assume everyone else in my extended team – it was a very big adjustment. Working agile is an approach so completely different, that it was almost like starting a new job, rather than just adapting how we work. During our change process, this was more often than not accompanied by feelings of uncertainty, sometimes confusion and frustration along with it. More importantly, it was more than just a little difficult to suddenly have to work so closely together within our scrum teams. With everyone feeling a little uneasy and overwhelmed by it all in the beginning, it didn’t exactly create the best atmosphere for productive team work. Moving from a process that is known, that I was good at, that I thought I had mastered, to this new thing called agile was a big deal!

Luckily, in my organisation, we had a lot of support. We had consultants who helped us learn the process and apply the methodologies in our project. And honestly, without them and their constant push to keep going and keep looking towards the benefits, I think a lot of us would have cracked and revolted to get back our nice, comfortable waterfall approach. Especially in the early days, when we were working through our very first agile release, it really isn’t all that obvious upfront, that agile really does improve the project, not just the output, but the day-to-day working within. For anyone wanting to implement agile in their organisation, the one thing that I would say you simply have to do, is get an expert in to help you, not just to explain the process, but have a “cheerleader” there to support, guide and motivate your team to keep at it during the tough times at the start.

Now, a few releases later, I can clearly see how working agile is benefiting us, both in terms of project output, as well as enjoying the daily interactions within and across our scrum teams, getting to know the colleagues specializing in their respective disciplines and gaining a much better insight into how we can collaborate and help each other achieve our goals.

I am pretty confident in saying that most of us have converted to agile scrum. We learnt it. We do it. We like it. Change is good.

Zero value.

I’m going to be blunt and honest: today’s post is going to be pretty short. Not that I don’t have new stories to share or ideas to promote, but today is one of those days, where I simply have too many things to do and not enough time to do them all!

So, instead of me writing a big long post, I thought I “cheat” and instead refer to you an interesting article I read just yesterday on the ScrumAlliance. The post is about “what is sprint zero?” About what it tends to be used for in many organisations and what it ideally should be. I found this is actually an interesting gauge to try and figure out how agile our organisation really is – and I think we might still have a way to go before we can claim that we have really and truly switched both our working model and our mindset to agile…

As described in this article, sprint zero is frequently used to plan your release, groom your backlog and put together design ideas – which, when you look closely, very much resembles a mini-waterfall. I have to admit to doing this myself, probably because I am relatively new to scrum and I think I am not quite there yet in being comfortable to just start “sprinting”.

Naturally, it takes a while to trust the process, and perhaps there is value in not trying to do things to soon – however there is still a little nagging voice in my mind that urges me to be careful and check myself so that sprint zero stands for “zero value sprint” and not “zero agile process”.

Showcase Discovery.

This week my team and I are once again faced with the question: How do I showcase work done in a discovery phase? Since our team is running on a sprint cycle like the other development focused lanes on our project, we are also expected to showcase our work every 2 weeks. In our organisation, and I presume elsewhere, showcases are not only use to actually showcase the new functionality and code developed, but also to keep track of the teams’ progress, highlight risks, challenges and get feedback on future development work if needed.

Of course, we can easily give updates on our progress, highlight risks and challenges, that part is simple, no matter what you do. Where I struggle is to find a good way to actually showcase the work my team  and I have done. Demoing work completed is all fun and games when you are showing fancy new software, but it seems a bit dull when what we have a produced is a required mapping document, written a bunch of user stories, maybe drawn up some flow charts and logged our work on questions, answers and follow ups on a spreadsheet. All of this work is necessary, important and very relevant to ensure we are discovering and documenting the best possible solution, but it doesn’t make for a very entertaining showcase…

And then, there is the other, far more important aspect, that the showcases are supposed to be a forum to gather feedback, float opinions and ultimately leave with suggestions on how to make our solution even better. This part is especially important to my team, since we are working in a “pre-user engagement” environment, where our only feedback comes from internal sources, most of whom are the people attending our showcases.

So, the question is, how can we condense all the complicated discovery work we have done into a bite-sized, easy to understand solution overview that will allow us to get the feedback we need to get to the best possible solution for our product and our users? At this point, I’m afraid I don’t yet have the answer, but I’ll keep trying different things until I find one that works…

Any suggestions or ideas?

Transfer complete.

I’ve been pondering for a while now on what will be the most successful method to transfer our findings from our discovery sprints to my fellow product owners… I work on a pretty big project and we have a team of several POs who each work with their own scrum team. Since one scrum team cannot handle the work required for the functionality me and my team have been researching, we need to be ready to hand most of it off to other teams. We already handed over a couple of smaller pieces of functionality to be developed, with satisfactory results, however the remainder of the items is significantly more complex and therefore I expect it will be much harder to successfully transfer all the knowledge over to our colleagues.

One thing I found challenging is how to educate the team on the priority of the various epics and stories at a glance. We do prepare and provide them with the key user stories we believe are going to drive success, however it can be overwhelming to go through a big excel sheet of data, trying to figure out which items are the most important, which are related to or dependent on one another and what would be the most logical and effective sequence to work on them – not to mention the fact that often these epics and stories need to be slotted in next to other items on the team’s backlog slated for the same release…

I hadn’t yet come up with the ideal solution, so I went snooping around the web and came across this article on the ScrumAlliance website by Andrea Gigante about using story mapping to manage the product roadmap and release backlog. Being a very visual person myself, this approach immediately struck a cord with me, as it represents the product backlog not as a long list of items, but a clear visual grid, already prioritized by both feature and story.

I was hoping to find a model that provides a quick yet comprehensive understanding of the functionality we are targeting, which stories are related to which epic and their respective priorities, but without going into too much detail, so as not to interfere with the teams’ individual estimation and sprint planning processes. This application of story mapping may provide me with just that: my team can provide the basic structure of the story map by feature and related stories, whereas each scrum team can then go their separate ways and slice and dice the pieces as it fits in their sprint schedule, based on their estimations and velocity expectations.

I think this easy to grasp concept will be a great basis for handing over my team’s discovery work to our other scrum teams and POs, which we need to be ready for in a few weeks, so thank you Adrea for sharing!

I will report back when the transfer is complete.