14. Lean Learnings 2: What not to do?

This is sequel to an earlier post, and captures aspects that are commonly get out-of-sync between product stakeholders and development team.

1. This is top priority because CEO asked: Many such reasons are cases where stakeholders do not have visibility into resource estimates by development team, and/or product teams do not have visibility into business value as perceived by stakeholders. Such stories may not mature rightfully with acceptance criteria, and fitness of derived value in long term product ecosystem will be low.
2. Believing user story is a requirement specification document: Having user story on an index card is a good start. Along the way, it is important to capture conversations in other forms of documentation, and should be track-able from user story. I call this process "maturing" a user story.
3. Acceptance criteria is not as important as statement of need: Statement of need is, again, a start. Acceptance criteria is confirmation of need, and should be carefully penned down, and as a indicator of size of user story.
4. Describing how to implement a story: Agile product development teams own the process of development, and are expected to know the product well enough to decide "how"? This should be respected; business analysts and product managers should concentrate on crisply defining "what"
5. De-prioritizing technical tasks: This is common mistake with mature products, since business stakeholders do not have visibility into business value of technical tasks. In a user story, it is important to capture the cost of not addressing such needs, so that stakeholders and product development are in sync.