Scrum is a framework (a set of rules) that can improve (software) creation process in area of project management. It introduces rules, the team has to follow. These rules makes sense for me, this is why I think this is worth sharing.
Way of thinking introduced by Scrum is valuable not only in IT but also in other areas, including everyday life (although it is not as simple as IT). Here is a Scrum Guide that is short and simple – worth reading.
Scrum uses short steps
The idea is to implement new functionalities and have potentially shippable product at the end of each step (working demo). Step should last no longer than 4 weeks and is called Sprint. Each Sprint aims to implement chosen functionalities listed in a Project Backlog – a list of tasks required in a project with priority and complexity for each of them.
Scrum is agile.
It means that it follows the Agile manifest and allows project team to dynamically change the scope of project according to the market and/or customer requirements. After each Sprint,the product backlog is adjusted, so the priorities or tasks can be changed. This is extremely important in R&Ds where reacting on a market changes is crucial.
Scrum improves communication.
Scrum requires a set of meetings to be scheduled. Before each Sprint there is a sprint planning meeting, that should last for about 8 hours for a 4 weeks long sprint. At the end or sprint the sprint summary meeting shall be held.
However the best part of scrum methodology are daily scrums – 15 minutes long meetings held everyday by a project team. Each of team member answers shortly three questions:
1. What he did yesterday?
2. What is he going to do today?
3. Are there any obstacles that interrupts his work?
Thanks to daily scrum, the whole team is aware of status and tasks in progress all the time, is able to react fast to remove obstacles as they appear and adjust working pace. And last, but not least – they can provide and receive feedback from other team members.
Planning sprint
How much the team can do during a sprint? It is assesed basing on historical sprints achievements. Amount of work (which relates to task complexity in a project backlog) is measured in a unitless unit :) Let’s say that the team handled to do 15 units during last sprint. Then probably it is able to do the same in future sprints.
How to assess task complexity?
By measuring the task You already know how complex is (for example 5 units) and comparing it to the new task. Then You have to say something like ‘this task is more complex, so its complexity would be 10 units’. Scrum is about basing on a history and experience.
Scrum roles
Are very well defined and described in a Scrum Guide. Thanks to separation of duties the Scrum can succeed – this is crucial.
Threads
You have to trust your team members. It is easy to fail if You believe that the scrum is introduced just to control You and check how do You perform. If You think so, then probably You don’t trust in Your team’s good will or Your team truly doesn’t have a good will, which is the worse case.
Myths
‘introducing Scrum requires fighting with company’s resistance’. I don’t believe it :) why the company would resist? Just be optimistic.
Scrum is most effective only when fully implemented. However taking only the best parts from it is also an improvement. In my opinion such parts are Daily Scrums and way the task complexity is assessed. Best part of scrum is fostering communication and fast reaction on market changes. These makes it surely worth trying.
Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality
Thank You!
Looks OK! 
i would add two important things :
– sprint tasks/tickets are not dedicated but each one is free for any developer to handle.
– sprint should be a closed thing (after planning no more tasks should be added there within sprint period). If addition occurs, it means planning went bad
Is there an assumption that each developer is skilled in every area? or it depends on developers skills?
my practical experience is low so some nuances are still not clear for me
Thank You for your valuable clarification!
each developer is skilled in every area <– this should be final state;]
Now i’ve got a name for it: this is so called ‘Truck factor’ – how much harm will Your project get if one of Your developers will be hit by a truck :)
If each developer is skilled in every area – then this harm is low, and Truck factor is low. Because every team member can handle task of the guy that was hit.