If I could, I wouldn’t: Separate back-end and front-end user stories

In my experience with Agile projects, we usually have user stories that somewhat correspond to features. Under the user stories, there’d be the front-end task, the back-end task, the testing task, and so on. There’d occasionally be user stories that’ll only have the front-end part or only have the back-end part, and that’s done as needed by the requirement. But it wasn’t a case wherein you have that particular requirement and you split it off to back-end and front-end stories.

I guess it’s always the team’s call on how they would work. That’s what makes agile agile. But I’ve tried it, i.e., having separate user stories for the back-end and front-end part. And it’s not my favorite for the various reasons I’ll enumerate below. Maybe it’s also just me and how I agree with that Agile principle that “Working software is the primary measure of progress.” Technically, the APIs could work and they’re functioning as expected; and the screen components are front-end validations could also work. But it feels incomplete for me.

Anyways, onto the reasons….

Repetition, Overhead

There are a lot of details that we have to repeat in both stories for the same feature. Why not just link them with each other? Well, we do that but the back-end guys expect that they can just focus on the BE story, same with the front-end guys. So there’s overhead in the repetition and in keeping things consistent.


We have to line up the BE user stories first or a sprint ahead. Then while we’re grooming for the next sprint or a couple of sprints down the line, we have to remember whether the FE story has already been covered by a BE story. Of course, that’s what related links are for. But still, humans are human, linkages could be missed.

In case there’s a bug in the user story, but it wasn’t really in scope, typically in previous projects we’d just create the needed user story for it. We’d then decide if it’s something we can take on within the sprint, or if it’s something we’d have to defer. But in this case, we’d need to line up two user stories — first for the BE and then another one for the FE, and there’s the possibility that we can’t get them in the same sprint.

Maybe it’s just psychological, and maybe it actually is, but it feels like it takes longer to complete a user story (feature).

Bloated Backlog

You nearly have twice as much user stories. So it feels like the backlog is bloated. You see a lot of user stories and it feels like a lot of work, but it’s just for that single feature or requirement. Again, maybe psychological.

Demos during Sprint Review

There’d be demos of the FE story which is already an integration of the back-end along with it, so that’s the actual demo of the feature. But there are also the demos of the BE stories where the interface would be via Postman or via Chrome Dev Tool or via the SQL client. As a tester, you have some appreciation for it; but as someone who empathizes with the client or business, I wonder if they’re as keen on seeing that API response as opposed to seeing the integrated feature.

Coincidentally, a team mate just asked me for certain details of a user story

So while writing this post, a team mate asked me for certain details of a user story. As expected, the related API story was linked to a corresponding FE story. However, she was working on a related feature and so that one wasn’t linked to the original API story. So it had to take some searching to find the answers from her. I ended up answering from memory to give her quick feedback, but of course I had to do due diligence and cross-check with the actual story and then add the linkages. Anyway, I guess this is my cue to get back to work. Although at 1:27 AM, I think I can already call it a day.

Continue reading

Interesting… DoD is defined by the development organization

All along I thought it was supposed to be defined by the Scrum team — with the development team and the Product Owner aligning on the Definition of Done. That’s how we’ve done it in the past projects I’ve had. But then I’ve come across a material saying otherwise. Apparently, based on the 2017 Scrum Guide:

…If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”.

To be fair though, there was no convention that we knew of or that we were advised to adopt. And so the Scrum Team went ahead to define “Done” (which apparently is more consistent with the 2020 version).

My past projects happened to be consistent around our DoDs. Unless there’s some exception which then had to be documented in the acceptance criteria, to be considered “Done”, user stories generally were…

  • dev tested
  • peer reviewed
  • deployed in the test environment (via automated scripts)
  • tested by testers in the test environment, with all major to critical bugs resolved
  • reviewed by the BA in the test environment
  • reviewed and accepted by the PO in the test environment

Looking into the 2020 Scrum Guide, it seems they changed it such that if there’s no such organizational DoD, it’s the Scrum Team rather than the Development Team (as in the 2017 version) who defines it.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

Thank goodness for that SQL training

The other day, one of the testers in the team raised a concern to the developers. He shared that he was trying to insert a record and there was an error. Now I’ve known SQL to be informative in case there’s such an insert error; and true enough, the error mentioned the problem with a Foreign Key constraint. I guess the problem was he didn’t know how to interpret that Foreign Key constraint.

This just made me appreciate the SQL training that I got from my first company. In my first two weeks in the job, I remember my SQL training consisted of being asked to read Teach Yourself SQL in 21 Days. Afterwards, part of the exercises was an existing bigass report that was programmatically generated that I had to recreate using one SQL query–down to the data format conversions.

Of course initially I didn’t appreciate the Data Definition Language (DDL) part as much. For testing, my work was more focused on the DQL and DML parts (Data Query Language, Data Manipulation Language). But, of course, as you encounter errors with your insert or update statements, you get to appreciate the DDL part as that lets you know what you did wrong in your statement.

Over (*BLEEP*) years later, I still find SQL and that basic understanding of a relational database such a valuable part of my skill set. And its value to me has definitely extended beyond testing. It helps me figure out what entities and attributes (shown or visible) would be needed to accomplish certain functionalities as I do my PO or BA work. It helps me communicate with devs e.g., when explaining how something should be retrieved or when I need to describe certain classes of objects to them. It helps me spot inefficiencies in some implementation (e.g., when they were retrieving the latest status details from a history table, or like when they concatenate something when they store it into one field then forgot they had to edit it separately).

Come to think of it, aside from being useful, SQL, RDBMS and database design are pretty interesting too. Or maybe that’s just me having learned to love my work. 🙂

[Edit] If anyone’s reading this, please share good references on the topics in the comments. Just maybe for reference of anyone else who wants to get started.

That dot-dot-dot menu (…)

My teammates and I were grooming a user story and we had to document certain expectations around that particular icon. I initially typed it in as “context menu (…)” which I learned later on that it wasn’t. And my teammates told me that they just call it the dot-dot-dot menu. Well, that works. But I was curious as to what it’s officially called, so I googled.

– dot dot dot menu
ellipsis button (singular) according to Microsoft documentation guidelines
More according to Apple
– more options
– others: meatballs, dumplings
– burger
– hamburger
navigation icon according to Google
– kebab
– vertical ellipsis button
overflow menu according to Google

I mentioned I got it wrong about the “context menu”. One of the results I came across had a description for the context menuContextual menus aren’t triggered by a consistent UI element. They appear next to where a user taps, and their actions can vary based on the tap target.

Anyways, one image result that turned up summarized those icons quite nicely:

Classic watch-out: Test emails

This is a bit of a classic watch-out. I say classic because this is a bit of a faux pas that I’ve heard of or even encountered way before, that newer generations of testers still encounter. Whenever the app or system being developed requires test emails, one thing we need to be careful with is to not send out test email to unintended recipients.

Just a few sample cases I’ve heard of

  • Site leader receiving test email notifications
  • Test email used was too common or was very likely to be real e.g., john@gmail.com
  • Fictional email addresses using an existing email service e.g., mail.com were used, but it wasn’t known whether those email addresses were or were not in use

If the domain of the email address isn’t limited to the client’s domain, then one option is to use a Gmail email address for testing. For example, if your main Gmail email address is didacticfiesta@gmail.com. Then there are two email hacks you can use to come up with multiple email addresses, all of which can be used to receive email via your main Gmail email address.

Plus (+) hack
Append “+” and some keyword before the ‘@’ sign. E.g., I also used the appended text to capture the teams or hierarchy in some of my previous tests.

  • didacticfiesta+captain@gmail.com
    • didacticfiesta+hulk@gmail.com
    • didacticfiesta+spiderman@gmail.com
  • didacticfiesta+archie@gmail.com
    • didacticfiesta+jughead@gmail.com
    • didacticfiesta+betty@gmail.com

Dot (.) hack
This one, I don’t really use so much. But it’s an option if the application under test is having problems with the “+” special character. Insert “.” within the email address before the ‘@’ sign. E.g.,

  • didactic.fiesta@gmail.com
  • di.dac.tic.fies.ta@gmail.com
  • d.idacticfiesta@gmail.com

OPP and that Wardley thread

Just a couple of reads I found very interesting this morning.

First is (OPP) Other People’s Problems posted in Medium by Camille Fournier. I’m a firm believer of how it’s so important to choose your battles because (1) not everything is worth it, (2) time is finite and you have to prioritize, and (3) maybe it’s not even your problem to begin with. That post shares some tips and someone had shared a flow chart for how to decide where you spend your energy on.

Second is this thread in Twitter posted by Simon Wardley (the guy behind Wardley Mapping). It’s about one particular customer making a very unique request, and Mr Wardley saying it’s a bad idea. For those of us who’ve been there–getting that very special, super-specific request that feels like it’s more effort than its worth–then this feels very relatable.

That unfinished podcast (with suggestions on how to improve at work)

I listened to a podcast just last week and I didn’t even get to finish it. I meant to resume it but the link no longer works (here’s the link just in case it ever becomes available again). But within the fifteen minutes I paid attention to, I got to hear the following tips in bold and jotted down a few notes (not so comprehensive as I was only passively listening).

  1. Don’t just learn, loop. – Do your job a little better every day.
  2. Do less, then obsess. – Be brutal in your prioritization. Saying yes to many things -> mediocrity. Master few things. Cut out all that other stuff.
  3. Become a forceful champion. – We achieve through others, we work with people we don’t have authority over… Inspire, build alliance.
  4. Fight and unite. – In good meetings, we are discussing (fight). Unite part is about decision, no undermining. [Link to YouTube video of author explaining Fight and Unite, around 3 mins]
  5. Disciplined collaboration. – Big problem is overcollaboration. Disciple the collaboration — on few things, most important things.
  6. Redesign your work. – Look into how can you do your work differently, better… frequently, not just annually.

The guest in the podcast was the author of the book and I had to google a bit to find out that the guest and book were Morten T. Hansen and Great at Work: The Hidden Habits of Top Performers (2018). I also came across the video of the author explaining “Fight and Unite” (added the link above).

Reaching for goals

Heads up, this is a brain dump! But come to think of it, all my other posts are. 🙂

I think there’s often an emphasis on knowing what the goals are, and even the why behind those goals. We see a roadmap, a strategy plan, some high level visualization of what we’d like to accomplish. But the devil is in the details. It’s in the how where things get muddied (all the more so if intent wasn’t clear to begin with), and which makes all the difference whether we actually reach our goals or not.

One of my favorite quotes has always been:

A goal without a plan is just a wish.

What prompted this post is one of the Medium posts that showed up in my feed today. It’s about The four simple habits of exceptional leaders. And Habit 3 is “Becoming process orientated, not goal orientated.” The post comes with a convenient takeaway point:

“Takeaway point: By focusing on improving the way we and our teamwork to achieve our goals, and forming habits of always seeking to improve how we work, we will ensure our goals are continually met and exceeded.”

And I agree. I’m not dismissing the what and the why aren’t important, because they are! It’s just that the how is just as important. And part of the how includes the nitty-gritty stuff like

  • working agreements
  • communication plans
  • team dynamics
  • good meeting practices
  • plan-do-check-act stuff
  • execution details especially who does what, how to check if on track, etc.
  • retrospectives
  • lessons learned

And generally looking at how you’re working (or not) towards your goals including reevaluating if those goals are still relevant. Half of me feels like these are basic stuff, the other half tells me we don’t know all these by default… we get to realize their importance over the course of many projects and hopefully not too many failures. This is why leadership is so challenging when you want to do it right — it requires experience (not measured in years), knowing to be in the present and at the same time have hindsight and foresight, seeing both the details and the big picture, serving across different levels sometimes with conflicting priorities, the pull of many directions that you somehow need to balance to keep on moving forward.

Read: Clarity First

The book Clarity First: How Smart Leaders and Organizations Achieve Outstanding Performance by Karen Martin is one of the books that often show up among the recommendations whenever I’m shopping for books to read at Amazon. It’s a bit too pricey for me though at $19.25. Luckily, it’s available through our office subscription to Skillport.

As I read it, there was a lot of what feels like a statement of the obvious or the author preaching to the choir. But I guess the value of this is that I get to read better elaborations of stuff that I feel just make sense but couldn’t explain as well. There were also a lot of parts that were good refreshers — stuff that I’m pretty sure most of us know but forego in the rush of being too busy.

For my notes here, I just noted what felt new, was a value add to me, or something that highlighted a point that I often overlook.

  • Chapter 1 is on clarity vs ambiguity
    • Self-assessment link
    • The A in VUCA as different from its three other friends (Volatility, Uncertainty, Complexity) “since ambiguity is a man-made condition that exists within the other three”.
  • Chapter 2 is on Purpose
    • I came across gemba or “the real place” where the action happens again.
    • The chapter also has some guide questions to aid in thinking about purpose.
  • Chapter 3, on Priorities
    • It reiterates the often ignored point on multitasking i.e., that it’s not as productive as most folks think it is.
    • TIL Ishikawa, that I only know for a fishbone diagram, was a Quality Management professor in the 1950s.
    • It has a section on creating a strategy deployment plan, which is a good point of reference to compare with how you’re currently doing it.
    • There’s a reference to “leader standard work” in the footnotes. I’m not sure if that’s a Lean reference thing so it’s something to google for later.
  • Chapter 4, on Process
    • Interesting quote: “A business is the sum of its processes.”
    • In this chapter, she goes into value streams which is also something she had co-authored another book on.
    • TIL of three productivity-robbing “enemies”: muda, muri, and mura. Muda refers to all forms of waste, including overproduction, overprocessing, errors, rework, excessive inventory, waiting, excess motion, excess transportation, and underutilization of people. Muri refers to overburden on equipment and people. Mura refers to unevenness.
    • “A well-designed process creates the potential for success, but execution determines whether the design is fulfilled in such a way that it meets its potential. And execution is wholly dependent upon whether the organization has people with the necessary level of skill, experience, and authority doing the work.”
    • Well-managed processes are documented, current, followed, consistently monitored, and regularly improved.
  • Chapter 5 is on Performance, so concept of KPIs are definitely not far behind.
    • TIL of levels of the scorecard. With Level 3 at the organizational level and usually with a maximum of nine KPIs. Level 2 KPIs are relevant to a business unit, division, or department, depending on organizational structure. And Level 1 KPIs are particular for a department or work team.
    • Hawthorne Effect is where people behave differently when they know what’s being measured.
  • Chapter 6, on Problem Solving
    • Need to differentiate problem solving from problem mitigation.
    • “Problem-solving skill building is the most important aspect of people development. Viewed through this lens, problem-solving coaching is the primary role of the leader.”
    • It highlights why there should be a singular problem owner; when everyone is accountable, no one is accountable.
    • Interesting: ‘One of our common warnings is: “When you automate waste, you get automated waste.”‘
    • The whole sections on CLEAR problem solving (Clarify, Learn, Experiment, Assess, Roll out) is a good refresher.
  • Chapter 7, You, asserts that the hallmarks (the five P’s of Purpose, Priorities, Process, Performance, and Problem Solving) of organizational clarity can also apply at the personal level.
  • Chapter 8 is on Committing to Clarity — it’s something that you take one step at a time, intentionally and consistently practice until it becomes habit.

Read: Where the Action Is

I’ve just finished reading up to Part Three of the book, Where the Action Is: The Meetings that Make or Break Your Organization by J. Elise Keith. The fourth and final part of the book has chapters which can be read separately as each chapter dives deeper into each type of meeting. But even up to just Part Three, there’s so much to takeaway from the book. If I had money to burn (which I don’t) AND I’d be guaranteed that recipients would actually read it, I’d give away copies of this book.

What I find interesting about it is the idea the author shares on how it seems like a cycle that meetings are bad because we’re already resigned to the idea that meetings are bad. So people use it as a crutch or as an excuse. Instead of actually doing something about it, they just think it’s not going to be worth it anyways. There’s also the idea of some individuals misusing meetings to further their egos, as a means to dominate, rather than to advance the team’s goals. So for such individuals who shine in dysfunctional meetings, it’s not in their best interest to “fix” meetings.

Coincidentally, I came across this quote: “For the great doesn’t happen through impulse alone, and is a succession of little things that are brought together.” It’s from a translation of Van Gogh’s letter to his brother, Theo. And I think it highlights intentionality. In the same vein, if you want to have your meetings actually turn out productive, you really ought to take the steps to drive it to that direction.