Gamify release planning!

While designing Minimum Viable Product, ever thought of gamifying release planning?

I created and implemented this,
the energy in the workshop and the outcome of the product was amazing…

Cross 5 levels to get to the release backlog/MVP features
Level 1 Success – Personas Defined
Level 2 Success – Feature wish list defined
Level 3 Success – MoSCoW and KANO (Wow factor) added
Level 4 Success – $ value attached to each feature
Level 5 Success – Spend your $100

MVP features are handy, now prioritize, deep dive and get going with your release.

Here is a detailed version:
Gamify Release Planning

Snapshot:
Gamify Release Planning

Feedback welcome!

Risk and Velocity burndown together might be better

jishasharma

BurndownRisk Burndown1

Recently got introduced but quite like it already. 

Quantify risk in each sprint, and then plot it. The risk should burn down with the velocity. 

How to quantify risk? 

  • Identify risks in each sprint
  • Quantify
  • Add all risks

Do the same for each sprint, as the relative values are used, quantifying is pretty much your way…

Risk Table (can be added to the backlog with points and then tools generate risk burndown automatically)
Risk Burndown

This can be used by senior management for quick project health checkups. E.g. Sprint 5 and 6 is when team might need help.

View original post

Usability testing – ask NOT tell

If any of you facilitates usability testing then check this…we all know it is not straight forward to drive a usability testing session

3 safe and productive approaches:
Echo – With the echo technique, the facilitator repeats the last phrase or word the user said, while using a slight interrogatory tone.
Example:
User: This page is funny, hmmm, not sure what, uh…
Facilitator: page is funny?
Facilitator: Why do you think the page is funny? 
Facilitator: Let me explain…

Boomerang – With the boomerang technique, the facilitator formulates a generic, non-threatening question that she can use to push the user’s question or comment back to him.
Example:
User: Do I have to login to checkout?
Facilitator: What do you think?
Facilitator: Yes, there is a link on the right…

Colombo – With the Columbo technique, be smart but don’t act that way. One way to do this is to ask just part of a question, and trail off, rather than asking a thorough question.
Example:
User: If I click close here will I lose my selections?
Facilitator: Uhm, you are wondering if [pause]
Facilitator: No, Close will save and close, and OK will save and proceed 
User: I am just not really sure if I should pick “close” or “ok”

Overall, we should focus on triggering information than giving a download…

Risk and Velocity burndown together might be better

BurndownRisk Burndown1

Recently got introduced but quite like it already. 

Quantify risk in each sprint, and then plot it. The risk should burn down with the velocity. 

How to quantify risk? 

  • Identify risks in each sprint
  • Quantify
  • Add all risks

Do the same for each sprint, as the relative values are used, quantifying is pretty much your way…

Risk Table (can be added to the backlog with points and then tools generate risk burndown automatically)
Risk Burndown

This can be used by senior management for quick project health checkups. E.g. Sprint 5 and 6 is when team might need help.

Proxy Product Owner role, I think it is needed…

“Proxy Product Owner”, in this onshore/offshore agile world is a secret sauce to address the gap between the business and the development team. A proxy product owner is co-located with the development team while the product owner with all the business knowledge sits miles away. There is so much that can be done as a proxy and also there is an option to only stick to the mechanics. When I say mechanics I mean only restricting to writing stories in the backlog, planning etc. Proxy can become a note taker from the PO or choose to rather “mirror” the PO to begin with and then further develop into a “thought partner”. If a proxy doesn’t attain the “thought partnership” then, like today, the role will indeed be debated.

Ask these questions to yourself and if the answer is “No” for any of these then may be the role might lose it’s charm…

Q1 Do you ensure that the development team is happy?

Proxy should ensure that the development team is happy, a happy team is productive and will work for good and the good will automatically make the client happy. Proxy is just at the right place to do that. 

Q2 Do you constantly measure and try to improve?

Let me explain with the help of an example. Track velocity and risk for a release and this would give you enough to understand what went wrong and will help you give a better shot next time. Unless you measure and analyse you live in a false world. Also when you measure then you are better equipped to resolve a problem.

Also have retrospectives and work on the action items religiously. If all your projects have the same issues then may be the problem is “you” than anything else.

Q3. Do your stakeholders always trust your product decisions?

If they don’t trust your decisions then you are not needed. Who needs just another layer in decision making?

Q4. Are you always in the main scene? Do you always have a pulse of what’s happening with the team?

Proxy constantly gives the direction to the development team, if you are side tracked then the team probably is not moving in the right direction.

Q5 Do you sometimes feel like you don’t have the right tools to solve a user challenge/team challenge/opportunity?

You need to gear up and experiment. You work with best of the technologists and if you are not tech/tool savvy then they probably won’t like you. Also it is a win-win. Ultimately tools will ease your life too.

Q6 Does team always have and respect Definition of Done (DoD)?

It is very important to have a DoD that is mutually agreed by you and the team. If it is agreed it will most likely be respected.

Q7 Do you ensure that backlog items estimates are created collaboratively by the people who will do the work?

Estimates should always be given by the person who would work on it else it’s unfair.

Q8 Are the top items in backlog small enough to fit in a sprint?

Proxy should focus on making requirements uncomplicated and that can be done by slicing and dicing the problem. The better you are at that, the simpler the problem will become. Small is usually simple and big is usually complex. If you give themes to the team then you are not needed, PO is more than enough.

Q9 Do you engage end user in every sprint for the feedback?

If you don’t then team indeed will work on changes later. Essence of agile is taking customer feedback as soon as possible.

Q10 Do you think before you say a “No” even when you are sure that it is not a “Yes”?

Last but not the least…don’t be a “Yes” man/woman. Team should mutually agree to a “Yes”. Also you need to put extra effort to ensure that every “Yes” is what the customer needs else you would build another software that is not adopted.

Let’s together work hard to make this role as a much needed role than a role that is debated on…

Look forward to hearing your comments…

These are only my thoughts, who am I? a proxy… 

Image