Agile is a Adaptive software development. Think "Agile " as synonym for flexibility
"Scrum is a framework for developing and sustaining complex products. (...) Scrum
employs an iterative, incremental approach to optimize predictability and control risk." (The Scrum Guide"™ - https://www.scrum.org/Scrum-Guide)
- It is hard to write bways to better measure and communicate the value of your code and related work.
DEFINITION OF DONE
One of the most painful thing to define. I think dod should answer these question
- Is it ready to be released?
- Definition of done, is about the quality of the code.
- Has all of the documentation that the organization requires been updated?
- Does the code have a reasonable level of unit tests?
- the code covered by system level tests?
- Has the code been reviewed by one other programmer?
- For business people: “If we ship this today, can we make,save money ( by reduce waste)?”
- Group of people who do the work of delivering releasable Increment of “Done” product by the end of each Sprint.
- They are self-organizing.
- Size of team starts from 3 up to 9 (on average 'best practice opinions)..
There are many way to do estimates but I learnt one thing.
Estimates are forecast not commitment!
If business treat them as commitment then there wil
Time based vs point based.
Although ,I liked time-based estimate tor a bit of time , because they give nice imagination and projection of what's will happen but this create a minefield ..one mistake and KABOOM
However, I discover time-based estimation suffer
It is a very danger tool for company where
Estimation of bug fixing is a mistake. I never seen this work.In fact , I prefer kanban aproach to bug fix
Problem is how
Truth is that great agile people, if you use this tool
Points are more accurate but less precised
One thing which is missing for me is defition of units we using..
For example when you using points system like 1 2 3 5 8 ...
What's defition of 1 and How many points are more less description of 1 day of work
- Estimates are forecast not commitment!
- Don't estimate bugs .From what I see it causes more problems and disorganize sprint.
There should be one gold rule ,that estimate and achieve goals "on time" as part of
- Sprint Planning:
- For example "Add Bluetooth Test"
- All information required for story must bed completed and groomed
- Decide which stories to do in this sprint
- [TIP] It sometimes makes sense to prioritise a risky story higher to just learn,
- [TIP] leave some space for unexpected events (bug fixes ,thing can take longer due complexity
- Sprint forecast sounds better than spring commitment
Link to article: Pair Programming is Best in Discovery Mode
Today, I found an article about Pair programming.
I can only add ,that I agree with opinion that
- Product manager tend to jump to the first acceptable solution without trying to consider other, (radically) different and perhaps better alternatives.
- PO is like an entrepreneur , an innovator , system thinker and mini CEO .
- PO is not a Business Analyst!
- It is responsible for maximizing the value of the product and the work of the Development Team.
- Manage Product Backlog items (CRUD operation and prioritize list
- It must be a one person. (entire organization must respect product owner decisions)
- No one except Product Owner is allowed to tell the Development Tram what to do and when.
- Person is like process owner who is responsible for ensuring Scrum is implemented correctly and works smoothly.
- Update the team's definition of done (or write one if they don't have one)
- Instead of maintaining an impediment list, remove each impediment the day you hear about it
- Should be described using this formula
- Given ( context ),
- When ( action ) ,
- Then (expected result)
- Product Owner
- the Development Team
- Scrum Master
- Don't planning for more than 3 months.Don't bother. from my experience, planning for longer
- Product must share a common definition of “Done”.
- Fix crap code immediately because bad code accumulates . If fix is more than "one liner" or not sure about it, consult your technical/practical leads
- Email is great for communication, but not collaboration. All collaboration should be done by accessible by team tools like Jira, Wiki
- Meetings must be meaningful. “Is this meeting important to getting your job done?”
- Don’t Estimate Software Defects
- Pair programming (link: http://itsadeliverything.com/pair-programming-is-best-in-discovery-mode
- A major factor in your choice of Agile framework/methodology depends on the ‘Reaction Time’ your team needs in order to change their currently agreed scope of work.
- For Scrum, the agreed scope is the Sprint Backlog (1, 2, 3 or 4 weeks long)
- For Kanban, the agreed scope is staying within your WIP limit threshold(s)
- Scrum is more about spirit rather than practices. I
- Agile Manifesto
- "The Scrum Guide"™
- Must read guide,if you planning to use Scrum.
- Peer feedback( http://java.dzone.com/articles/continuous-improvement-scrum)
- According to Wikipedia "Peer feedback is a practice in language education where feedback is given by one student to another”.
- Nice comics that explain how kanban works:
- "A late change in requirements is a competitive advantage"
- by Mary Poppendieck
- "As humans, we have a hard time acknowledging we don’t have control over everything. Hitting the estimates serves as compensation for not knowing everything. Drilling through the known unknowns, compensates for the unknown ones. "