Skip to main content

Eat the Frog!

Eat the Frog!

Have you ever started your day with a task which you kept on deferring for the next day? You probably have. Well, welcome to the club. Most of the us are appalling at time management and task management. Remember the saying a “Well begun is half done”.

It is extremely important for all of us in our Professional as well as Personal lives to tackle arduous tasks first so that the very thought of “work to do” doesn’t keep on lingering.

This blog is targeted towards the Business analysts/Product owners/Project Mangers/Agile participants as my examples are going to be very specific and can be applied in general also.

Who is the Frog for us in our everyday routine?

Replying to emails. Important mails only. But this should be the first thing in the morning.
Getting a sign off on an important document

Setting up various meetings before time runs out

Remember last night’s call, customers gave an important requirement which was complex to understand but you were busy eating and checking your phone? Well This is a big frog. Make sure you record the meeting or have notes handy. You always tend to miss on details

Setting up weekly deliverables. Various names for this monster like sprint planning, roadmap for the week, team tasks, project planning. Not doing this can be risky since team doesn't have a clear idea on how to proceed. They know what to do but not know when to do and this is planning. In my personal experience, planning needs some extra time especially when there is major interdependency on the developers end

Brainstorming ! You are trying to solve a major problem but somewhere you are not satisfied. That’s frequent. To get this job done easily, always try to compile a team who a mix from dev to testing. Ideas flow seamlessly 

Happy Eating!

Popular posts from this blog

Do you really need a Business Analyst in your project ?

Do you really need a BA or a similar fulfilling role in your project?

My Aunt has been in a Real estate and construction business for long time. When I was a kid, I used to visit her to every now and then to spend some time. As a part of the visit, I was often told by my cousins that she is at the construction site. 
Building a small house over a chronological period I got to experience how the house was built from scratch. I saw how the construction workers did the job as they were guided by the contractor. 
I also experienced that when it comes to big buildings, there is always an architect who creates the blueprint of how the house is going to be, what dimensions the rooms are going to be.
Notice how this is an analogy for any system we build. Our systems can be small where you don’t really need a Product owner/Business Analyst or we need somebody exclusively who is just for gathering/writing the requirements.

 If you are building a mid to large-scale system, you do need to have a dedi…

User Stories Simplified!

User story writing guide
When I was introduced to the world of Agile, I kept on hearing the words  “User Story”. I couldn’t apprehend what it meant and how it possibly could be a fit for requirements management. This was all due to the traditional waterfall methodology which was omnipresent in most of the software projects. Early in my career we totally relied on creating massive amount of documentation which included but not limited to *Business requirements document Software requirements document High level design document Low level design document Use cases
 You can clearly see where the problem lies if you are planning on to maintain all these documents. On top of that, if you are working on mammoth projects, good luck with that!
How does user story  might prove to be user full?
First of all, User story is not a Silver Bullet but a convenient way to represent requirements. More precisely what a user intends to do.
In my case study, I am going to use example of “loremipsum” which is a social …

Product Management

Product Management

Once I had a conversation with one on my friends who just happened to join a startup. He said he worked as a Product Manager and was talking in general about roles and responsibilities .
What surprised me was that his roles and responsibilities differed from what I have seen in the market. Nothing wrong with it, this happens with other roles also. 
Product management roles vary depending on organisation to organisation. It is hard to define the roles and responsibilities. Though all have a common goal to making the product successful but vary depending in what department you are in or what phase part you are working on. Example : Some folks work in the analytics are Product Manager.

Talking about my friend, he was more into forecasting for the application, looking at the revenue growth. When asked about who builds the road map, his answer was that the tech team and the business decide.  A fairly common scenario. 
So what are the Roles and Responsibilities of a Product Ma…