0 Post(s) for May 2019

List of Entries

Recent Posts

“Everything is vague to a degree you do not realise till you have tried to make it precise” – Bertrand Russell

When it comes to understanding and documenting requirements there always seems to be a discussion and room for improvement. In general we capture a user story in an automated tool with a summary / title and a description that has both the user story (“as a”, “I want”, “so that”) and a section describing the “Conditions of Satisfaction” (aka “Acceptance Criteria”). People wonder “how much is too much detail?” Others wonder whether they really understand the requirement in enough detail to do something useful. Still others think that we should write a complete specification.

One team I worked with recently ran an experiment using a slightly more formalized approach to capturing Conditions of Satisfaction which helped us understand the requirement, but also did not specify how solution was to be derived. At the time we were trying to solve a problem with the (acceptance) testing of the workflows but found that the solution we worked also helped us improve the discussion and collaboration around the requirements.

By way of background, when we tested during the first phase of the project, while we had good requirements, we really had not taken the time to develop a good test plan, relying instead on an ad-hoc approach. The result was that we did not feel we had covered all the basics. We felt that we had duplicated efforts in some areas. To improve we decided to capture the acceptance tests during the development of the requirements.

For the second phase of the project we used a format for the Conditions of Satisfaction which is related to acceptance test or behavior driven development. The basic format of the acceptance criteria is described as:

Given <some initial context>
When <an event occurs>
Then <ensure some outcomes>

The work we were doing involved the flow of data between Siebel and JIRA. Let’s say we have a user story “As a support engineer I would like see what is happening as people discuss and work a Siebel issue so I can ensure that it’s heading in the right direction”, we would then write the Conditions of Satisfaction as “Given a person is in working in JIRA Agile, when the person adds a comment to the JIRA issue that is linked to a Siebel CR then the related Siebel record notes will by updated with the comment”.

Just like the user story format helps us capture and understand not only the feature but who needs it and why this format for the acceptance test helped us capture and understand the acceptance criteria from an end user’s perspective. It also helped us understand what it meant to test the capability when that time came around, forming the basis of our test plan. It really increased the amount of discussion we had about the requirements, and made things clearer for everyone.

Some of our requirements did not easily fit into this format. For example we had a number of requirements that given a condition, we'd have certain mappings go between the two systems. For these we simply captured a table of conditions, inputs and outputs. I will say it sometimes seemed that it took a while to get to a definition that we all agreed on, but I think that is the point - this also helped with collaboration and clarity as well.

It should be noted that when you capture acceptance criteria in this format they can also be the basis of an automated test using tools like Fitness or Cucumber to actually run the acceptance test. But even if you do not do this, it is worthwhile experimenting with the approach as it really helps with collaborative communication ensuring everyone gets on to the same page.

Note: Good starting book to read if you want to learn more is "Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing" - Gojko Adzic.

Note: this posting was originally published in August 2015 on a Wordpress Blog

I finally got around to publishing the presentation I did at the Agile 2016 Conference this year. Title for my session was “How to Work Personality Issues Without Sounding Like a Marriage Guidance Counsellor?” It was basically a presentation on approaches you can take to deal with conflict without coming across as disingenuous.

The session was well attended (about 120 people) and received positive reviews, so I was happy. A number of people came up to me during the conference to talk to me about the specifics.

Full set of notes and materials are at Hans Samios - How to Work Personality Issues Without Sounding Like a Marriage Guidance Counsellor? The PowerPoint slides includes a full set of notes.

Also, my notes on the conference are at Agile 2016 Conference in Atlanta, GA. Note that this is still a bit of a work-in-progress.

Read and enjoy!

2016/08/15 18:27 · hpsamios · 0 Comments · 0 Linkbacks

As part of a plan for the day, I pull together a list of meetings that will happen today and put an estimate on the meeting based on the scheduled time for that meeting.

As I've watch myself work these I've found that this approach grossly underestimates the impact of the meeting on my day for a number of reasons:

  • Meetings typically require preparation. Unless the meeting is one that is on a cadence, meetings seem to require about the same amount of preparation as the actual length of the meeting. Even meetings on a regular cadence often need some level of preparation work (for example, Sprint Review requires that I put some words together to describe what happened during the Sprint).
  • Meetings typically have follow-up actions. Unless the meeting has been mainly about communication of ideas, there will be some level of actions and recordings required from the result of the meeting. Even meetings on a regular cadence have these (for example, weekly Penguins meetings has specific actions for me, and a requirement to record the results in some place.)

My plan for today therefore typically includes:

  • The actual meeting. The meeting itself is time-boxed. If you have taken the time to get others involved in the meeting, there must be some level of importance. The work is classified as (I)nvest so as you get to the end of the time-box you should ask “what value will we get out of extending this meeting?”
  • A “meeting preparation” task which serves both as a reminder that something is coming up, and as a placeholder to actually do something. The typical work is administrivia or low level research to get a feel for what you think about the issue (without necessarily forming hard conclusions) and so the work is classified (O)ptimize. Sometimes a lot of research is required to prepare for the meeting, in which case you might look at additional tasks that are probably classified as (I)nvest.
  • A “meeting followup” task to address actions, take care of any recording. Typically this is the administrivia as well as dealing with the actions means new user stories and so the work is classified (O)ptimize.

The impact is clearly larger than the meeting itself. For a 1 hour (~2 iterations) meeting, we typically have 1 hour (~2 iterations) of preparation work and 30 mins (~1 iteration) of administrative follow up work. On a fully booked 6 hour (12 iteration day) you are looking at 5 iterations for any meeting in the day,or ~40% impact on the day. Huge! The impact is probably more than that in that the meeting often represents a context switch and often (say 50% of the time on average) is scheduled so that I do not get a complete iteration to do work (ie interrupted, or more likely I simply don't bother to start an iteration.)

If this level of work is required (and I think it is in order to make sure that meetings I call are effective) then I need to question if I call a lot of meetings each and every day, am I really being effective?

2016/06/20 18:51 · hpsamios · 0 Comments · 0 Linkbacks
You could leave a comment if you were logged in.
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/blog/start.txt
  • Last modified: 2017/10/11 22:21
  • by hpsamios