[Business meeting] The Expert (Short Comedy Sketch)

[User stories] Invest in knowledge, it pays the best interest

Even, slightly modified, this quote from Benjamin Franklin applies to writing good user stories.

A way to assess your user stories is to check if they meet the requirements dedined by Bill Wake's INVEST acronym in 2003. Bill Wake also repurposed the acronym SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) for tasks resulting from the technical decomposition of user stories.

• Independent  - We want to be able to develop in any sequence.
• Negotiable  - Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
• Valuable - Users or customers get some value from the story.
• Estimatable - The team must be able to use them for planning. 
• Small - Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
• Testable - Document acceptance criteria, or the definition of done for the story, which lead to test cases.

For more detail, User Stories Applied by Mike Cohn (pdf file)
* Real quote: "An investment in knowledge pays the best interest." - Benjamin Franklin

[TEST] Move forward, shift left!

Companies following Agile development practices intend to test often and have frequent releases. But sometimes, you can’t: For example, if you are part of a large enterprise with complex web applications using for example service-oriented architecture combined with legacy systems. Another problem is that the majority of testing is usually done once features are completed, after SIT (System Integration Test) and UAT (acceptance test). You can almost never test the quality of a system. Then, the time spending at the end of a cycle testing and bug fixing is going to be bigger than it could have been if you had found and resolved the issues earlier in the Software Lifecycle. Studies shows that it’s a lot more expensive to fix a defect found once it has been released. The shift left concept brings a concret solution. It tells you what can be done to improve overall quality and at the same time accelerate release cycles. The intention is to bring new services to market faster, drive growth and/or maintain competitive edge. The goal of this methodology is to shift as much of the testing prior to release (to the left, during construction) and catch errors earlier in the software development lifecycle. To achieve this:

• Create automated and continuous test through all quality stages
• Have a single version of the truth for the quality of your deliverable
• Create and run automation as a part of the development process
• Ensure governance of your testing end to end.

[User stories] Size does matter…

As a professional working in an agile environment you should be familiar with estimations of the effort needed to complete user stories.  Commonly referred to as "story points these effort can be estimated effortlessly if you relax and use well known techniques. Remember that the founder of scrum mean that story points are meaningless. Their real value is a relative value, compared to other user stories.

The team members must feel confident about the process, about their colleague and speak up! 


“The biggest risk is not taking any risk... In a world that changing really quickly, the only strategy that is guaranteed to fail is not taking risks.” Mark Zuckerberg

To start, you and your team need to determine a satisfactory measure of complexity and size. Example: Very low, Low, Medium, High or you could use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, …) or even T-shirt size (xs,s,m,l,xl).

Techniques:

Triangulation: Even when you know nothing you know something. You can compare, use experience, similar stories and reach an estimate.

Fist of five: The story gets estimated then everybody vote on that estimate (number from 1-5). Strongly disagree = 1, strongly agree = 5. The team members who voted 1 or 2 should explain before a re-vote. You stop the process only when everybody's vote is like or above 3.

Polling (planning poker): Each team member writes down (or holds up a card) what they think the story will take independently. The highest and lowest estimates should give explanation to the team. May be something new will be revealed. The the team can adjust and vote again and reach a consensus.

To conclude, we are only humans. Studies show that developers have a hard time estimating for others than themselves. What if the task is to be done by someone else, and what if there are a lot of ad-hoc tasks during this very sprint. Different people have different ways to manage their time and consider risks...so in reality the team member with the largest estimate might be right…If you have to choose, take the largest estimate!

[BPMN] Aim for the architecture repository

 It is common to encounter BPMN diagrams those days.  The modeling notation is victim of its success and broadly use in the workplace. But what about its core definition, it’s standards, they are simply washed away by the urge to draw quickly an interpretation of a business process. Basically a quick win.

If you want your work to end up at the correct place: the architecture repository, then spend some extra time to review and improve your diagrams.

Re-open the specifications, check some basic rules.

For ex.:

·         A subprocess MUST have a None start event; it’s a spec violation to have a triggered start in a subprocess

·         Message flow represents communication between the process and an external entity.

 Happy modeling!

[SCRUM] The whole is greater than the sum of its parts

SCRUM teams should aim in achieving a synergistic effect, and I quote Aristotle "The whole is greater than the sum of its parts". High-speed, high-stress world, communication is key.Learning to listen will improve productivity.Teamwork is about cooperation not attitude. Get the Most Out of Daily Stand-up #SoftwareDevelopment #DailyStandupMeetings