Failure appears when something you assumed proved to be false. That’s the time to review our axioms, with the honest willingness to change them if necessary.

For a Product Management perspective, the longer you wait to realize an assumption is false, the more expensive it is to change what you built over that assumption.

The “cost of changing what was built” as time passes and the probability of the happening that in fact it was a bad assumption is what I understand as risk.

Here my six practices to embrace and live comfortably with assumptions, risks and priorities:

1. Associate a risk numeric value to each assumption.
2. Associate a risk description and the correspondent assumption to each User Story.
3. Before starting the product development, be sure to have cleared all the higher market, platform, technology risks.
   • Refine your persona.
   • Talk A LOT with users fitting your persona.
   • Continue refining your persona in the process of talking.
   • Review market penetration of the platform and technology used by your product.
   • Review market trends.
   • Review the Business Strategy of your company.
4. Star developing those User Stories with higher Business Value and those with the higher risk associated. Answer the tougher questions first.
5. Pay consulting services to a Subject Matter Expert to review the iterations increments. This is a review process independent, not related to the Team Review Meeting. Remember the team presents the increments to the Product Owner, not to the SME, at least of course the PO is the SME.
6. Start a customer base, even when you have only the concept of the product.

Further Reading

Brutal Prioritization in Agile: cut costs by NOT building the fluff

People who looked at this item also looked at…

• Scrum Release Planning
• Costa Rica Agile: Let’s bring the revolution here
• The impact of Human Resources in the Agile Enterprise
• Predictive Planning vs Adaptive Planning
• Agile is about Reality not Fairy Tales

Related items

• Scrum Release Planning
• Predictive Planning vs Adaptive Planning
• Attaching Business Value to User Stories
• Stop being in pain
• The task board shows WHAT and HOW we are doing during a sprint

A group of people come together, create a sufficiently shared understanding of an equifinal meaning that enables coordinated behavior, and then the actual activities of task identification, decomposition, distribution, coordination, and integration of outcomes are accomplished in a manner that lasts long enough for the goals [...] are realized.

That’s the definition of Collaboration as stated in Luke Hohmann’s article Some Answers to What’s Collaboration? .

Enforce collaboration. Agile practicesare meant to enforce collaboration. Think about it:

• A dedicate workspace for team.
• The workspace is in itself a meeting place, so anyone can convoke a meeting at any time without waiting for meeting room to be available.
• The team is working in a circle-like distribution, everybody facing averybody.
• Pair programming.
• People participating in Daily stand-ups are talking to everybody, not only to ScrumMaster/Leader.
• The ScrumMaster enforces a shared vision.
• Openness in any meeting, specially in Retrospective meetings.
• Shared agreement in decisions, even in controversial matters.
• Reflect and Inspect what went wrong and right in each iteration (Retrospective meetings) in order to improve teaming.

Further reading

How to set up a productive working environment for Agile teams

Pair Programming with VNC

Organizing an Agile Modeling Room

People who looked at this item also looked at…

• Costa Rica Agile: Let’s bring the revolution here
• The impact of Human Resources in the Agile Enterprise
• Coping with Quality Assurance Issues
• The wisdom of knowing when to use Agile
• Certified ScrumMaster Training

Related items

• The task board shows WHAT and HOW we are doing during a sprint
• Costa Rica Agile: Let’s bring the revolution here
• Six Practices to deal with assumptions, risks and priorities
• No agile practices or processes are substitutes for a Roadmap or Vision
• Usability Test: Want valuable feedback? Recruit real user for testing

A very engaging aspect of Scrum (and Agile in general) is to find innovative ways for solving problems found in the Retrospective meetings. By the way, the Retrospectives are are rich well of requests and improvement opportunities. By pandering to those requests (and inspecting at the solutions) you will get a tailored improvement to the process.

How do we at Artinsoft do for keeping track of our Sprint progress using the Task Board? Let me explaining it to you by telling you the story.

We have acknowledged that the following phases are needed in order to set a done criteria for the User Stories we committed:

• Design: Meetings to discusses architectural issues,
• Development: Coding
• Application Quality Improvement: Pair Programming and/or Code Review. We prefer Pair Programming.
• Testing: Quality Assurance in the way of Developer or Integration Tests
• Usability Tests

Additionally, a sixth kind of tasks emerged: Environment, as a mean to say that it is a task that encompasses all the environment setup (technology setup) to accomplish the User Story.

Well, in one Retrospective long time ago we pointed out that some User Stories were lacking of enough quality. Why? …. Got it! one or more aforementioned phases were being skipped when planning and implementing features. Why? We EASILY forget to get sure we get them while planning and even implementing. At the second level of “Why?” we realized we needed something catchy to remember those phases and to avoid the constant tendency of realizing them when the deadline is looming, or even worse: never!

We devised a solution: Use a specific color for each kind of task when doing the Sprint Planning and do a Color Distribution Assessment constantly: Do we have enough of all colors for all User Stories? If not, is there a unanimous and intentional awareness of it?

Our Taskboard looks like this:

We always have a good supply of sticky notes next to the TaskBoard, one color stack per phase or kind.

Along the Sticky notes we also have a supply of red round labels. Why so?

In the diagram, I pictured an hypothetical second day of the Sprint, in the Stand Up. The team member David (hence the “D” in the sticky note) delayed more than the recommended (and estimated) one day for that pink task (Usability) he committed to finished. He sticks a red round label to the task and in that way the Task Board is irradiating to the whole team that we are behind of the Sprint schedule.

Again, this has worked for us and fits to our specific circumstances. What do you think about it? Feel free to give me your opinions, all your comments are needed and welcomed!!

People who looked at this item also looked at…

• Costa Rica Agile: Let’s bring the revolution here
• Scrum Release Planning
• No agile practices or processes are substitutes for a Roadmap or Vision
• Getting even more serious about your meeting problem
• The impact of Human Resources in the Agile Enterprise

Related items

• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Collaborative environments to achieve goals
• Coping with Quality Assurance Issues