Cognitive Load

You might have recently come across the term “cognitive load” (or if not, now you have) being thrown around lately. While I haven’t really read about it, I have a sort of guess of what it is but initially in the context of usability. Ages ago, I read this book entitled Don’t Make Me Think and what I got from it is the idea that the design or the implementation of a certain functionality has to be made in such a way that it is as intuitive as possible. When the design is incoherent with its purpose, that makes you think — and unnecessarily so — somewhere along the lines of “why?” or worse “WTH?” and that contributes to why a certain screen is not so usable.

Beyond usability, the idea sort of still applies.

When something feels like it lacks clarity, it’s incoherent, it doesn’t seem to make sense, it doesn’t seem to add up… those things make us think. Instead of being able to focus on moving forward or on the thing that we have to do, a part of our brain is stuck at trying to make sense out of things. So that to me is the sort of “cognitive load” that we need less of. It’s like brain activity that doesn’t get us to where we want to go any faster.

Now I can’t just be throwing around the term without at least trying to learn more about it. Just sharing this quick 20-minute YouTube video (around 12 minutes if you skip the Q&A) that gives a short and easy-to-understand explanation on it in the context of managing information overload.

A quick summary that they provide:

“We constantly need to learn. But there are limits on our ability to learn. Cognitive load theory can help us work within those limits giving us a set of guiding principles. If we manage intrinsic load by breaking large tasks into smaller ones, reduce extraneous (irrelevant) load by eliminating irrelevant tasks and distractions, and increase relevant (germane) load with appropriate repetition and varied learning context, we promote efficient learning, improve productivity and escape the horrors of info overload.”

A simple story of Nobody

This was something I picked up from high school (or maybe even grade school). I think it stuck because I was fascinated with the wordplay and its having a strong message contained in it even though it was so short and simple. The story goes (just that one paragraph that follows):

This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was asked to do it. Nobody knew Everybody wouldn’t do it. Everybody was sure Somebody would do it. Anybody could have done it, but Nobody did it. In the end, Everybody blamed Somebody when Nobody did what Anybody could have done.

I find that you can take it in different contexts — at work, for some chore at home, in society — and it still works. And it’s a sad story when nobody does what somebody or everybody should be doing.

The only thing necessary for the triumph of evil is for good men to do nothing.

Lessons from Leadership is Language on Feedback

That title couldn’t be any more explicit. I spoke with a colleague who shared a challenging situation she’s in. After our talk, I couldn’t help myself from thinking what if I were in that situation and had to be the one to make that difficult conversation. I also took it as an opportunity to revisit what I read about from Leadership is Language by L. David Marquet, and relate aspects or lessons from the book on to the context of giving feedback. Of course, I can’t share the exact examples here, but I tried to give close enough explanations.

Give information, Not instructions

  • Instead of saying “You should do this or that,” try to provide the information that would reasonably lead to that suggestion (or maybe even better suggestions from them).

Focus on behavior, Not characteristics

People will have better control over their behaviors, than on characteristics they have.

  • Instead of saying “You’re an ineffective ______________,” try citing the specific behaviors that led to the idea that they’re an ineffective whatever.
  • Same when it’s positive. Instead of saying “You’re a great team member,” say the behaviors that you’d like to be repeated.

On the process, Not the person

While I think asking one’s self “How can I be a better <insert role here>” is good for introspection, asking that to another person might not always be taken positively. I think we are naturally defensive and we can’t expect everyone to be consciously going against that natural tendency. Asking “How can you be a better leader?” might somehow be misinterpreted as “You’re not a good leader, you suck, you really need to improve…”

  • Instead of asking that, shift focus on certain processes. Say that person’s responsibility includes owning say the peer review process, then instead of asking “How can you be a better peer reviewer,” ask “How can we improve on the peer review process,” “What do you think can we try to better track the peer review comments,” etc.

Observe, Not judge

I think this ties up with the previous items on focusing on behaviors and giving information. By trying to take a non-judgmental stance, ideally we get to show that we are not condemning the person, that we are open to working with the person to address the objective information provided.

  • Instead of (judging the person) “You wrote that report poorly,” or (judging the work) “That report is poorly written,” provide the observations instead “I noticed three spelling errors in the report”.

I just reused the example from the book here. With that example, it feels easier, clearer or more achievable to address the “three spelling errors” compared to a poorly written report.

On achieving excellence, Not avoiding errors

I think asking how to avoid errors is a fair question to ask because that is something you want to achieve. This also works well for me for introspection. But related to what I mentioned previously, asking that can be taken negatively even if you don’t mean it to be. “How can you avoid so-and-so” might come across as rubbing salt to the wound or might feel like the focus is on what the other person is doing wrong.

  • Instead of asking “Why do you keep on missing those bugs” (which also feels accusatory and it’s often not the case that people intentionally try to miss bugs), ask “What do you think can we try to find those bugs sooner?”
  • Instead of asking “How can your outputs be less buggy,” ask “What do you think are we missing in our process so that we can get things right in fewer reviews as possible?”

In writing about this, I have had a little more time to think about it. But the challenge I guess is making these conscious word choices on-the-fly or when the situation unexpectedly calls for it.

Lines that resonate to me as a tester

I’ve started reading this recently published book by Ozan Varol called Think Like a Rocket Scientist. I’m only at the first chapter which is about uncertainty, and I came across these few lines which I found interesting. As a tester or reviewer, you come across bugs. While it can mean a little more work for the team, sometimes you can’t help admit that some of the bugs–or whatever little things that trigger them–are cool or fascinating. Maybe it’s just me. But say hi in the comments if you appreciate cool bugs once in a while.

Anyways, here are those quotes. Those three blocks below are from the book:

“Discovery comes not when something goes right,” physicist and philosopher Thomas Kuhn explains, “but when something is awry, a novelty that runs counter to what was expected.”

Asimov famously disputed that “Eureka!” is the most exciting phrase in science. Rather, he observed, scientific development often begins by someone noticing an anomaly and saying, “That’s funny…”

Einstein’s younger son, Eduard, once asked him why he was famous. In his reply, Einstein cited his ability to spot anomalies that others miss: “When a blind beetle crawls over the surface of a curved branch, it doesn’t notice that the track it has covered is indeed curved,” he explained, implicitly referring to his theory of relativity. “I was lucky enough to notice what the beetle didn’t notice.”

Reaction to 9 leadership mistakes

I came across a post in Medium entitled New managers: 9 leadership mistakes you don’t know you’re making. I’m not a manager—and not even considering a managerial career path—but that really hasn’t stopped me from reading about leadership and organization. And after having read it, I don’t think the content is just for new managers anyways. Regardless of being old or new or even just about to be in a leadership role, it’s good to be reminded (or warned) of the possible mistakes you might be making so that you can do something about it.

I was initially going to react on a couple or so points, but ended up writing what Medium estimated as a 5-minute read. So below are the mistakes shared in the post. For each, I supplemented with my own points and, for some, reiterated points I wanted to highlight.

Mistake #1: You think building trust is about team-building.

While it is an opportunity to make a connection (but it’s still up to you to make the most out of it), it’s not enough. The post author shares this link giving the three most effective ways to build trust as a leader: (1) Show vulnerability as a leader, (2) Communicate the intent behind your actions, (3) Follow through on commitments.

Try to think about how your own leaders built trust with you (or maybe how they didn’t), and use that to amplify your own trust-building experience with your own teams.

Mistake #2: You think your team members generally know what’s going on.

We’ve heard of over-communication, or even “hyper-communication.” But this quote says it best:

The single biggest problem in communication is the illusion that it has taken place.

So how would you know if your message gets through? One is that you’re getting the right actions out of it, but that might take time. One other way is to maybe talk to some members of your team—include the ones who people usually talk to—and ask for feedback.

Communication is such an exercise of empathy. Try to put yourselves in your audience’s shoes, and then ask yourself what would you (as them) get from hearing what you (as them) just heard.

Mistake #3: You believe being busy as a leader is good.

Don’t wear busyness as a badge of importance or of being effective. If you’re too busy, you’re time-poor. When you continuously work like you are so pressed for time, that has high chances of taking its toll on quality. It could be on the quality of the actual outputs since you might miss some details. Or it could be on the quality of your interactions—you might leave people feel like they’re not heard or seen even if you have squeezed a whole one hour for them.

I guess there might be some who feel exhilarated with busyness. And it’s OK. Just don’t let that diminish the quality of your interactions with the people you work with.

Mistake #4: You sort-of prepare for your one-on-one meetings (when you have the time).

Nothing says you have their best interest at heart better than putting in the work to actually show it. And that includes setting aside some time to look into what you’ve previously discussed, what news can you share that’s relevant to them, what concerns have reached you that relates to them, given whatever’s happening recently what would be the right questions to ask them. Check out the link that was shared how to prepare for your one-on-one meetings.

And as you go into that one-on-one, remind yourself that the meeting is not about you or your causes or your agenda. It’s about them.

Mistake #5: You try to solve the problem yourself, because you’re the domain expert.

Sometimes people will approach you asking how would you attack a certain problem they’re experiencing. I think I’ve been lucky because folks who ask me usually have already given the problem a lot of thought and would just like to have an nth opinion. So just be there to hear them out, and give your two cents if asked. But ultimately, solving the problem will be up to them.

Being in your position though, there’d be things you know—that they might not—that could help them like certain contacts, or references, or other available options outside of what they may be privy to. So be a means to connect them. You don’t necessarily have to go out of your way setting up all the needed meetings or doing POCs yourself. Again, solving the problem will be up to them.

Check out the link that was shared on the most counterintuitive leadership tip for more insights.

Mistake #6: You think transparency all the time is good.

When things aren’t clear or when intentions aren’t communicated well, there’s clamor for transparency. But as she mentioned, “transparency can backfire if you don’t hold two concepts in view: Transparency requires context, and transparency is on a spectrum.” The link she shared on how transparent should you be as a leader is an elaboration of this. Check it out, and here’s a quote from it that I wanted to highlight:

As a leader it’s important to ask yourself: In what cases is transparency appropriate and helpful, and in what other cases is it distracting or a burden? Are you being transparent, just for the sake of being transparent, or are you truly trying to help people make better decisions, and feel a greater sense of trust?

Mistake #7: You think you communicate the vision in your team well.

Again, I’m reminded of the single biggest problem in communication quote. Although not quite about management or leadership, a webinar I took mentioned how high level decisions influence low level ones. And it’s pretty similar. The vision or intent that you share to the team would create the actions that would push for that vision to be realized. Say the wrong thing, or don’t say it clearly enough, you get misalignment and what you get may be results that do not support the vision at all or as effectively as you wanted.

In terms of something actionable, I guess verbalize the vision in the context of your team. It’s possible that there’s some grand vision handed down to you, and if you can, distill it so that it’s more relatable and understandable for your team. And see Mistake #2 regarding communication.

Mistake #8: You think you’re giving enough feedback.

You recognize when recognition is due with “Thanks!”, “Good job!”, “Well done!”, and so on. But I think feedback that’s more helpful are the ones that will help people improve. But it’s hard when you’re not working on the same project together. You get some high level input that the project is doing fine, but you have no idea how well your team mate is actually faring.

Maybe that’s it—maybe you should work on something together.

Maybe you can look into the available structures at work that will allow for feedback to be openly and safely shared.

Mistake #9: You’re nice.

No, this is not a mistake. But I guess “nice” means different things to people, easy to talk to at the very least. But more than that, nice to me means being kind, being considerate, having empathy, playing fair, not being an asshole, and upholding respect for others and myself.

If you want only the easy, positive, fluffy conversations, that’s NOT nice. That could do a disservice to your team. To have honest, fair and helpful conversations, that’s nice.

If you’re always people-pleasing at the cost of putting your team members on a difficult spot, then that’s NOT so nice. Throwing people under a bus is not cool. Coming up with something workable IF you can and being able to decline IF you can’t — that would be nice.

You’re buddy-buddy with your team, that’s nice. But as their leader, are you helping them find opportunities where they can flourish? If not, that’s not nice. That you do your job as a leader effectively—and that includes upholding respect for the people you lead and letting them flourish—that’s nice.

That was long. If you’re here, thanks for reading this far!

Career Talk by my manager

My manager had a talk about career this afternoon via MS Teams. I think it went pretty smoothly. There were minor hiccups like one or two members of the audience momentarily not being on mute, so we got to hear some chickens (or chicken–we’ll never know) and other background noises. There was also this slight flicker between the virtual whiteboard and the slide deck whenever he was drawing (or maybe it was just my connection).

During the talk, there were notes being shared via the meeting chat by Hana and Roman. So I got those notes (in italics) and thought of adding in some of my own. Nothing fancy, just stuff at the top of my head.

Two most important things to develop your career

  • Self-development
  • Leadership

I think prerequisites to self-development are humility and the capacity to learn. You have to have the right attitude towards learning. You also have to work on how you learn. Find what’s effective for you and maximize that; find what doesn’t work for you and improve on that. As for leadership, I think the prerequisite of that is self-management. Before you lead others, you have to develop discipline to lead yourself.

  1. Identify what you want
  2. Have a career discussion with your manager
  3. Be open to explore roles so you can “sharpen your saw”
  4. Law of the Lid: Increase your leadership value

Apart from what you want, you also have to weigh that against your interests and what you’re good at. It’s important to remain grounded.

A career is a journey. It’s not linear. Be open to learn from it. You cannot do it by yourself–be open to work with people.

Some folks got into IT thinking they’ll just have to work with computers. But working with people is inescapable. You have to work with them for getting the requirements, for finding out what their problems are, and then for coming up with solutions, for implementing the solution, for validating the solution, etc. You’re in the business of solving problems for someone. You’ll have to talk to that someone, or their representatives, or someone (or most likely a lot of other folks) who you’ll work with to solve those problems.

Leadership will unlock your potential.

Getting to a particlar [sic] career path is not a straight line. It will involve branching out and exploration.

Take advantage of the people network that you will build along your journey.

It’s give-and-take. Sometimes by first being of service to other people, you get returns. Sometimes. And if you don’t, it’s still a learning opportunity.

Expect learning through failure. Don’t be afraid to fail.

On the other hand, there is some danger in thinking it’s OK to fail. Particularly if you become too complacent about it. “Oh, I fouled up… Oh, well, it’s OK to fail anyways!” It’s the learning that happens in failure that has to be emphasized. There has to be some semblance of accountability that you avoid making the same mistake over and over again.

Roles are more important than the levels.

When you’re trying to get to the next level, it’s taking on the roles that you hold exceptionally well that helps you get to the next level.

Convergence on managerial and technical paths are more evident nowadays.

Passion: if you are passionate on something, you know that you will always do your best on that field.

Re: Basketball bit from Eric – notice the evolution of the game + roles: point guards were just expected to dribble and pass, centers just on the shaded lane… and players were designated playing positions based on height. Now, forwards can play point guard, centers are expected to shoot outside…

Somewhat related to this, I’m thinking of reading Range: Why Generalists Triumph in a Specialized World? Anyone who has read it and would recommend it?

70-20-10 Model
10 = Training
20 = Relationship
70 = Experience

Don’t mistake “Training” to be limited to formal classroom training. It also includes the learning you can get from reading books or watching webinars or listening to podcasts, etc. It’s not just classroom training.

Your performance and value will decline overtime if we don’t continue to learn new things (Entropy).

It’s also a matter of translating what you learn to something relevant and helpful – be it by giving advice or guidance, providing inputs or ideas when asked, creating a POC, etc.

5 Levels of Leadership (John Maxwell)

  1. Role / Position
  2. Relationships
  3. Results
  4. People Development
  5. Respect

The five levels of leadership depicts why someone would follow a certain leader. The lowest level is the starting point, and I hope folks will have enough self-respect to try to rise above that. If it’s OK with you that people are compliant to you only out of the position you have over them, that also says a lot (or maybe the word is little) about you. Please try to prove your worth, try to be trusted.

Think Win-Win
How can we work together to make this “pizza” bigger?

Idk. I just want pizza now.

Integrity creates a condition of workability.
An essential quality in building your career.

I often say that work is hard enough as it is… without being compounded with lack of trust or integrity. Having integrity makes working with you easier for others. Makes working with yourself easier as well–like when you don’t have to jump through mental hurdles of having to remember what you said to whom that might be inconsistent with what you said to someone else.

You have to try first. Acknowledge if you can’t do it but find ways on what you need to do to achieve your goals.

Main Focus in Career Development

  • Self Development – find your passion, what makes you different, and how you can collaborate.
  • Leadership – Applies to all levels and roles. This will mamiximize [sic] your potential.

Sometimes it’s hard to know where your passion lies, or what’s your key differentiator, or what you want to do in life. There are some who are still finding themselves. And it’s OK not to know or be a hundred percent sure. Just keep trying to figure it out, one step at a time. As Picard said (and maybe this has gone off on a tangent), “One impossible thing at a time.”

“I’m not technical.”

“I’m not technical.” I’ve heard this before countless of times. My knee-jerk reaction is usually thinking that: Wait, if you’re in a technical field of building or delivering software, you should be technical! At least in your role, you should be technical.

But then maybe I’m going with the rather loose definition of technical as being “(adj) of or related to technique.” I mean, there’s got to be some system that you’re using (or some method to your madness). You’re not just randomly doing random stuff (especially if you’re leading the team). There’s got to be some reservoir of knowledge or experience in your field that you turn to for figuring out how to go about things. To say you’re not technical would be like saying you’re leaving things to chance, or you don’t know what you’re doing.[1]

When people say that they’re not technical, I think it could be one of two things (maybe more if I had more time to think about this).

Maybe they’re just using the wrong words. Maybe what they really mean is: I’m not a programmer; or I’m not an SME of so-and-so technology; or I don’t know how to code; or I’ve only just started learning X; or I understand the logic but I don’t know the syntax in X programming language; or I have a high-level understanding of how it works or what it is, but I might need to consult with so-and-so for low-level stuff; or just a word of warning, I might not understand some jargon but let’s discuss; etc.

You might be undermining yourself, or you might unintentionally cause the confidence of the person talking to you to slightly falter. A suggestion for this is to elaborate or shift towards saying what you actually mean.

Maybe they’re using those words “as a shield.” Maybe they don’t want (or they’re too busy) to put in the effort to try to understand; or they’d just like to throw it over the wall and let the “technical” folks deal with it. This is not cool.

If the problem or topic is not your area of expertise, it’s OK not to know in depth about it. But you still have to understand it well enough if you have to make decisions around it, and more so if you’ll need to communicate this one or more levels up because then they might make decisions based on the inputs you provide. And regardless if it’s levels up or down, you’ll have to understand what you need to communicate.

Making the effort, and then gaining that understanding — There’s no harm in that. That can even help you be more effective and more relevant in the work we do.

[1]: For the latter, i.e., you don’t know what you’re doing… To be fair, I think it’s OK to be at that point, as long as you’re trying to move out of there. Don’t stay there too long.

Checking out: StaySafe.PH

I’ve been seeing tweets urging folks to sign up or check out which came out rather recently (just this Apr 10, I think). So I did.

Started in the landing page. What caught my eye, apart from the layout of the buttons, is that it offers contact tracing, health condition reporting, and it’s said to be a social distancing system.

I wanted to understand more, so I scrolled down… Disregarding the layout again, it tells me that StaySafe will remind me to keep distance from communities with COVID-19 cases, and StaySafe will give me tips on what to do if I happen to encounter symptoms (but they said “when” so that’s a downer).

I went ahead and registered. Afterwards, I logged in, and shared my health status. I’m then taken to the home page. The typo on “Lets” and the layout of those buttons are slightly distracting.

Now I’m at a point where I wonder where’s the stuff that it said it’ll do. Since I have no symptoms, I guess it’s pretty understandable why I didn’t get any tips. OK. Now as for the other thing “StaySafe will remind you to keep distance from communities with COVID-19 cases”. I’m pretty much staying put at home and not really going out all to other communities. Nevertheless, I’m looking at the home page and I’m thinking how is it going to do that? Maybe through those buttons labeled PH, MAP, and 3D under “COVID-19 Updates”?

I clicked on the PH button… and I pretty much just see stats that are also reported with better breakdown elsewhere. Also the DOH shared that they’re revising the classification from PUM (person under monitoring) and PUI (person under investigation), and will shift to using SUSPECT, PROBABLE and CONFIRMED. That’s pretty recent so it’s understandable why the site hasn’t caught up to that change.

Moving on… I click on the MAP button next. And it’s a map, fair enough. But I can’t do much with it. Can’t zoom in. Can’t see the communities with higher concentration of COVID-19 cases which would have been more useful.

Then I click on 3D next.

So I’m back at the home page thinking I’m not getting much use out of this. I revisit the article on CNN Philippines, “PH launches online COVID-19 tracking, emergency response system“. There it said:

“The data will then be sent to a “heat map” in the platform’s admin dashboard which will then show the areas and the number of people exhibiting COVID-19 symptoms.” Ah, so the helpful info is only available in some admin dashboard that I don’t have access to.

“The online platform was designed to help medical frontliners, local government units, private companies, as well as the national government, to monitor the health condition of residents and conduct more efficient contact tracing... Medical frontliners will receive alerts from the system, allowing them to immediately respond to severe COVID-19 cases and provide direct online consultations to patients.” Oh, maybe they should have gone with that in the page explaining what the site is for.

That’s about it I guess. Nothing much to do in the site, although I really hope I wouldn’t have to use it for reporting symptoms or seeking help.

Do we size bugs with story points?

I found a question posted in one of the social channels at work: How should one give out story points to bugs/defects that one does not yet know how to fix yet and requires investigation? The original question asks how but I think even before we go there it would be nice to know whether we need to in the first place. I plan to write about this in 2-parts: (1) how I might go about with it — no explanations, but based on past experiences as a member of Agile Scrum teams and what I’ve read on the topic, and (2) links and quotes galore.

How I might go about with it

  • If it’s a bug found during testing of a user story we’re working on in the sprint AND it’s small enough (implicitly sized) to be fixed within the same sprint: It goes into the sprint backlog. No need to size it. Just prioritize it accordingly.
  • If it’s a bug unrelated to user stories that we’re testing this sprint (say, from an older feature) OR it’s too big a bug or complex (again implicitly sized) to be fixed within the sprint: It goes to the product backlog. It’ll be groomed as you would with other user stories to give it enough details for the team to work with. And if it makes it way into the Sprint Planning, then size the bug.
  • Now what if the bug that goes into the product backlog requires more investigation than usual (all bugs require investigation, but in some cases I suppose devs already have an idea of how to fix it, in some, totally no idea hence more investigation is needed): Tag it as a spike (not a term in the Scrum Guide, FYI). If it goes into the Sprint Backlog, meaning the team agrees to invest time on investigating that bug within the Sprint, no need to size it.
    • For that spike in the Sprint, it’ll just mean there’ll be a time-box (1-3 days of effort) for investigating that bug. At the end of the time-box, whoever works on it reports their findings and the team can discuss the next steps.
    • Assuming the team agrees on a resolution, duplicate the bug with the spike tag. Close the original one. In the duplicate, remove the Spike label. If it’s to remain in the Sprint Backlog meaning the team will fix it within the Sprint, then size the bug. Otherwise, the new bug (the duplicate) goes to the Product Backlog and no need to size it yet.
    • But what if there’s still no resolution or identified workaround. The team can opt to extend the time-box. But at some point, you can’t just extend and extend it forever. Once a threshold is met (is 3 months too long/short?): Tag it with a label your team agrees to use on such items, and then archive it.
  • At the end of the Sprint, the Scrum Master will be able to gather the following data in case they want to use it for some forecasting:
    • User Stories – total story points, bugs per user story
    • Bugs – total story points, total number of bugs
    • Spikes – total number of Spikes worked on, total number of Spikes closed, total points from Spikes that were converted to new bugs

That turned out longer than I expected. The next part are for some links on the topic and could give you the opposing views to help you come up with your own answer.

Links and quotes galore

12 common mistakes made when using Story Points – This has a lot of other interesting points not just about on whether you size bugs or not.

  • “Story Points represent the effort required to put a PBI (Product Backlog Item) live.” So story points are not limited to user stories.
  • “Story Points are about effort. Complexity, uncertainty and risk factors that influence effort but each alone is not enough to determine effort.
  • [Common mistake #5: Never Story Pointing Bugs] “A bug which is unrelated to the current sprint should just be story pointed. The bug represents work the team needs to complete. This does not apply if the team reserves a fixed percentage of time for working on bugs during the sprint. A bug related to an issue in the sprint should not be story pointed as this is part of the original estimation.”

Should Story Points Be Assigned to a Bug Fixing Story?

  • [I think this is with respect to legacy bugs or when the team is dealing with a large database of agile defects] “My usual recommendation is to assign points to bug fixing the agile defects. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish, but also able to look at the historical data and see how much went into the bug-fixing story each sprint.”

Should you ‘Story Point’ everything? – This is a thread in the forum.

  • (No points for bugs) ‘They are called story points for a reason. They are not call[ed] “Item Points”. Ideally you should only have stories in your backlog and the technical tasks should be inside…’
  • (Yes or no points for bugs) “It is critical as a Scrum Master to ensure that story points are being used properly within an organization. They serve two purposes only: to help the Development Team and Product Owner plan future sprints, and to be accumulated for done items at the end of a sprint for velocity calculation purposes. They are not a proxy for value delivery. … That said, it seems there are a number of different items (bugs, technical tasks, spikes) that have a capacity impact on the Development Team each sprint. For planning purposes, if the team prefers to not point these items, a mechanism to determine the capacity impact is still desired….”
  • (No points altogether) ‘I have found, and this may depend on your team, that removing story points entirely helps the team and stakeholders focus on the sprint goal instead of “How many points”….’

What’s a spike, who should enter it, and how to word it? Since I mentioned “spikes”, I’ve put in this other link about it.

  • “A spike is an investment to make the story estimable or schedule-able.”
  • “Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.”
  • “It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.”

Let me know if you find anything more conclusive or helpful.

Read: Fast Times

I lucked out on getting a $0.99/month subscription to Kindle Unlimited (but only for a limited time–ironically). And earlier today, I found a new title that was just published quite recently. Coincidentally, it felt relevant because of some recent strategy/planning discussions that I’m hearing about. So I went ahead and read it.

The book is “Fast Times: How digital winners set direction, learn and adapt” by Arora, Dahlstrom, Hjartar, Wunderlich. It’s a short, easy read — finished it within half a day.

Some takeaways:

  • Speed is an outcome of deliberate actions and behaviors.
  • Emphasis on learn-and-adapt — ABL: Always be learning.
  • Bold aspirations must be matched by corresponding commitment. Tentative measures will not deliver.
  • Chapter 5 shows a few numbers illustrating how fast looks like (e.g., normal product launch is in 6 months, fast is in 2 weeks).
  • We’re inundated with how important it is to be safe to fail, BUT it’s not an excuse to say it’s OK to fail all the time. Chapter 6 supports that with its mention of “Failing is not always acceptable” with an enumeration of when it’s plain wrong.
  • “You’ve got to make sure that if you make mistakes, you learn from [them].”
  • Chapter 7 revisits the all familiar Tribe-Squad-Chapter-Guild model.
  • Chapter 13 just brings to mind how security needs to be integrated in development.
  • Chapter 14 shares the Digital Transformation Office’s (DTO) many roles — in injecting coherence to how squads are structured, in implanting importance of learning, in having visibility on what’s working (and not), in capturing, codifying, disseminating best practices, etc.
  • All that learning –especially from failing– isn’t worth much if no one can find it.