Is it ready?

Whether a user story is ready or not is a question I get asked during the Sprint Planning. I reckon it’s not really a question that I alone (as BA/PO/PPO) ought to answer. The Scrum Team answers that question. Prior to the Sprint Planning, those user stories had been groomed with the architects and dev leads, and they’d have been covered in the team backlog grooming sessions. And again prior to the Sprint Planning, the user stories for possible inclusion in the coming sprint are added into the Sprint Backlog for the rest of the team to preview so that they can have an idea of what makes sense for them to assign to themselves and so they can ask questions. During Sprint Planning, those stories are covered again and the floor is opened to questions if any. And even after Sprint Planning, the floor remains open for questions. The floor is just always open for conversations.

Now whether a user story can be absolutely ready is another thing. This is not a waterfall project where the designs had been laid out upfront. And even with a waterfall project, some questions arise only as you are implementing the functionality, or even as it gets tested in UAT, or even when it’s already out in production.

This is where the agility and the self-management of team members are invaluable in Agile. The grooming of user stories become a conversation (ideally among the three amigos–PO, Dev, Test) that feeds into the readiness of the user story. Is it ready? We make it ready. And as things arise (as they almost always do), it’s the agility and the self-management of team members that again becomes necessary for them to navigate through this rather than be stalled by each and every hiccup that comes along or rather than whining on how the user story was not ready. It’s as ready as we can make it.

---

I think I’ve digressed in this post. I initially wanted to write about how the Definition of Ready (DoR) is not even in the Scrum Guide. There’s this interesting post in Medium that details the history: The rise and fall of the Definition of Ready in Scrum (estimated by Medium as a 7-minute read).

Some of the points I highlighted:

• “All you need is a product vision and enough priority items on the backlog to begin one iteration, or Sprint, of incremental development of the product.” — Ken Schwaber and Mike Beedle 2001
• 2008 — First definition and inclusion in official Scrum Alliance training material… The DoR has the following traits:
  • A user story exists;
  • The “formulation” is general enough;
  • The user story is small enough to fit inside a Sprint;
  • It has its unique priority;
  • It has a description of how it can be tested;
  • It has been estimated.
• 2010 — First edition of Scrum Guide… 15 years after Ken and Jeff started discussing Scrum, they created the first Scrum Guide. This first guide doesn’t mention the Definition of Ready.
• “Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning meeting.” — Ken Schwaber and Jeff Sutherland 2011
• “Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.” — Ken Schwaber and Jeff Sutherland 2013
• “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.” — Ken Schwaber and Jeff Sutherland 2020

Retrospection and learning time

Just recently, my engagement to my project since Nov of last year has ramped down. So the past couple of weeks has been a time of transition for me into my upcoming project and also from me to the new PO of my previous project. This allowed an opportunity for retrospection, and also a chance to pick up on new stuff.

While looking up the available knowledge sharing platforms within the company, I came across the option to host stuff in our enterprise GitHub instance. One link led to another, and I came across…

• MkDocs – This is for project documentation; it allows the use of Markdown for writing content, and then you generate static site contents from that.
• Documentation as Code (docs-as-code) – While I’m not a programmer, getting familiar with the concept wouldn’t hurt. And as I read more, it’s not really exclusive to programmers.
• Diagrams as Code with Mermaid – Part of the family of stuff-as-code, this doesn’t trail far behind. I think what I find promising about this (apart from being free) is that this is going make comparison of versions easier since you’re comparing text files.

As mentioned, I did some retrospection. I collated some of my personal lessons learned and posted it in our project’s Confluence page. I also revisited Software Development’s Classic Mistakes. I tried rereading The Scrum Guide and some stuff on anti-patterns to see where we’re somewhat deviating (for guidance if it’s something we should continue or if we should “realign”). Then I tried to pull out project-agnostic stuff that could be helpful to me for starting a new Agile Scrum project and collated my notes.

With the notes in hand, I’m starting to use it as a reference for the new project, and I plan to just tweak accordingly as I find other useful stuff to add in. At this stage, there’s already a team working on the prototypes, and in theory, they’re prepping the solution or the design which will be handed over to the implementation team. So I’ll be keen on learning a lot more and looking for process improvements for the handover from Design Thinking to prototyping to implementation. Exciting stuff! 🙂

How our team “does Agile”

Super quick background: Our project started Jan 2015. To kick things off on the Agile methodology, our Scrum master conducted a brief training (less than half a day) to the team, and we’ve been playing it by ear ever since.

Over the course of many sprints, retros and releases, we’ve made adjustments on how we’re doing Agile. I’m not sure if there are Agile Purists who would frown down and shake their heads at us for the variations we’ve made. But the thing is, despite our possibly non-canon approaches, what still matters most is the team closely working together to deliver working software.

This post might be TL;DR. But in case you’re still interested in having a peek at how our little team does Agile Scrum, go on and have a read…

Hello again, world

I haven’t been in this space for some time. Lately, I’ve been instagramming about my lovely dogs and tumblring my attempts of doing art. I am still in software testing. I still feel that the work we testers do highly contributes to making software better (or at least less sucky).

I’m around month and a week into my 2nd mobile testing engagement. We’re at the 2nd week of our 2nd Sprint. There are a lot of things that are new in this project so it’s a really great learning opportunity for myself and more so for my younger tester team mates. For one, we’re adopting an Agile Scrum methodology, and it’s probably the closest we’ve gotten to an actual agile project (we have some scrumbuts). This project is also an implementation project, so this provides them with the opportunity to see something get built from scratch. I think testers who haven’t tried working in an implementation project are missing out. This is where the fun is, and where testing can make the most impact. Plus, this one’s building a mobile app so it has a really modern feel to it.

So tomorrow’s a holiday and we still haven’t received a build for half of the user stories in scope of this sprint or for the fixes of the bugs that were already reported, and Friday is the last day of the sprint. Ah, scrummerfall! It’s a word I picked up yesterday. One of the questions in a webinar I attended touched on the topic of agilefall or scrummerfall. It happens in Agile projects wherein the testing work starts at around the 8th day and the testers are scrambling to test the features and doing overtime work to catch up, and the developers are already moving on to other things. If you’re experiencing scrummerfall, sorry but you planned it that way. The good thing is you can choose to not plan it that way (or so the speaker says). Someone needs to raise their hand and point it out so that the team is planning for a sprint that has something testable as early as day 2 or 3.

Something to raise for our retro. :p