Sprint is the heartbeat of Scrum. All work in Scrum is done during Sprints. Sprint is a time-boxed duration of time. It is usually 1-4 weeks long. Sprints start with a Sprint Planning meeting and end with a Sprint Review and Retrospective meeting. Teams develop increments of functionality during Sprints.

I.T Project Management

Programming ventures change always. At the point when clients are relied upon to settle prerequisites before they can test-drive the models, overhead and long deferrals regularly cripple the venture. Agile Project Management is about grasping change, even late in the advancement organize. It€™s about conveying the elements with the best business esteem in the first place, and having the continuous data to firmly oversee cost, time and extension.

Agile – Scrum Project Management diminishes many-sided quality by separating the numerous months-long cycle of building prerequisites for the entire venture, fabricating the whole item and after that testing to discover several item imperfections. Rather little, usable sections of the product item are indicated, created and tried in reasonable, two-to four-week cycles.

BTMG USA – we help companies manage their projects so they focus on their business,clients & productivity with peace of mind.

project management practice

  • Poor Requirement Gathering
  • Faster Agile Delivery
  • better productivity using agile

You can transform your project management into an agile scrum practice based business focusing quality and improving delivery time with satisfaction.

how do we help

  • Analyze project management practice
  • Build Agile based Scrum project management practice
  • Implement procedures and processes
  • Knowledge Transfer
  • Periodic auditing for sustainable success in motion


Client satisfaction guarantees the future growth, but it is only possible when you have delivered a successful project / product, which starts from collecting the most accurate information as step one.

Business Process Management – planning, implementation using smart reusable techniques help not only save money but create a future ready scaleable solution.

Compliance & Governance help maintain the integrity of the solution, ensures from conception to delivery, security,best practices were employed without concession.


Agile is an umbrella term used to describe several iterative and incremental software development frameworks, processes and techniques. Agile helps you embrace change and enable you to develop and release in rapid, flexible and incremental fashion. Scrum is the most commonly used Agile framework. Other processes include XP (extreme programming), DSDM, Crystal and some variation of Kanban

Scrum is the most commonly used Agile framework. The Scrum Guide defines Scrum as “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”.Scrum is a framework, which means you can use techniques from other Agile processes like XP etc. in Scrum projects

XP (extreme programming) is an Agile software development process. It focussed on iterations (time-boxed short development cycles) to improve productivity, quality and responsiveness. Techniques like pair programming, unit testing and continuous integration stemmed from XP.

In today’s fast changing marketplace ignoring Agile is not an option anymore.Agile and Scrum enables you to

  • Respond to market changes deliberately while controlling risk
  • Outpace your competition. Ship early and often.
  • Build exactly what customers want. Not what you think they might want.
  • Optimize productivity and total cost of ownership

Scrum is one way of achieving agility. Scrum is the most commonly used Agile framework.

Literally, Kanban means a signboard or a billboard.Kanban is one of the systems to implement lean and just-in-time (JIT) production (or development). It was pioneered by Toyota. It helps determine what to do (produce or implement), when to do, and how much to do.

In essence, Lean processes aim to deliver value with as less work as possible, reducing waste along the way. It stems from Toyota Production System. Lean focusses on optimizing flow, decreasing waste, increasing efficiency. It leverages empirical methods to bring to surface what matters most (in a system) rather than accepting “this is how things are done”.

Scrum Master ensures that the Scrum framework is used properly. The Scrum Master guides and coaches the Team and the Product Owner. The Scrum Master is a servant leader role. The Scrum Master removes impediments to enable the Team become productive.

The Scrum Master is responsible for ensuring Scrum is understood and enacted.

  • The Scrum Master works with the Team and the Product Owner to enable the Team in value creation and delivery.
  • The Scrum Master removes impediments to help the Team become productive.
  • The Scrum Master guides and coaches the Team, the Product Owner and other stakeholders.
  • The Scrum Master works as a facilitator and servant leader.
The Scrum Master is a management, or rather a leadership role. The Scrum Masters work as servant leaders. Instead of telling people what to do and exactly how to do it, Scrum Masters emphasise self organization. They work as a guide and a coach, helping teams and organizations understand and leverage the Scrum framework and Agile practices
No. The Scrum Master is a servant leader role. The Scrum Master guides and coaches the Team and the Product Owner. No prior technical knowledge is required to become a Scrum Master.
Read the freely downloadable Scrum Guide. It’s the only official Scrum body of knowledge.
The Product Owner is responsible for maximizing value and return on investment. The Product Owner represents the customer. The Product Owner manages the Product Backlog (requirements).
The Product Owner works with customers, stakeholders and the Team to maximize the value of the product.
The Product Owner is responsible for maximizing the return on investment.
The Product Owner manages the Product Backlog.
Product Owner is essentially an Agile product manager. Product managers, programme managers, business managers or in other words people who are responsible for end to end product (or service) lifecycle are well suited to become Product Owners.
Read the freely downloadable Scrum Guide. It’s the only official Scrum body of knowledge.
The Scrum Team consists of the Scrum Master, the Product Owner and the development Team. The development Team, normally referred to as the Team is a cross functional Team. It consists of people with all required skills to turn selected items from the Product Backlog to done increments of functionality.
The recommended size of a team is 3-9 people. Less than three hardly make a team, it’s a pair. In cases where the team consist of more than nine people, it becomes increasingly difficult for the team members to communicate effectively. The Sprint Planning, Review and Retrospectives are all time-boxed meetings, which require focus and decision making. Bigger teams find it very difficult to make decisions within the given time-boxes, do estimation, design, development, testing and other tasks in an effective and meaningful way. The Daily Scrum becomes a pain to run.
Studies after studies have shown that co-located teams are more productive than distributed teams. Communication and productivity suffer a bit in distributed teams. However, Scrum does not require teams to be co-located.
Teams should consist of all the skills required to turn Product Backlog Items (requirements) into a product increment. They typically consist of architects, developers, tester, business analysts and DBAs etc
Teams work as a self-organizing unit. The Product Owner sets the goal and direction. The Team is given resources and time to achieve these goals. The team decides how best it can achieve these goals, given the resource and time constraints. The Scrum Master helps the team remain product by removing any impediments.
Teams (and individuals for that matter) are most productive when they working one project at a time. In a given time period, let’s say in a year, Teams who remain focussed on one project get more projects done as compared to teams who focus on several projects at the same time.Scrum does not require that the Team work only on one project at time, however, it will help the Team (and other around it) see the waste in productivity in cases when they are working on several projects a time
The total work the Team is capable of completing in a Sprint is called velocity. When the Team is planning its first Sprint, it estimates its velocity. For subsequent Sprints, velocity is the amount of work done by the Team in the previous Sprint. This is a guidelines for the Team to plan its work.
Learn more about Scrum and Agile Teams, cross functional Teams, self-organization in one of our
Product Backlog is a list of requirements (called Product Backlog Items). It is managed by the Product Owner. The Product Owner orders the Product Backlog according the value, risks, dependencies and business intention.
All the requirements, functional or non-functional, issues, bugs and documentation related work is put on the Product Backlog. It reflects all the work that a Team does. In other words, the Team does not do anything which is not on the Product Backlog.
The Product Owner defines the vision and direction which the Product should take. The Product Owner may define the requirements on her own, or work with the Team to do so. Any member of the Team may create items on the Product Backlog. However, it is the Product Owner who manages the Product Backlog.
The Product Backlog is changed on need basis i.e. it keeps changing whenever there is a need to change it (a new item is created, existing one is changed, the order of the Product Backlog is changed). The part of the Product Backlog selected for the ongoing Sprint (reflected on the Sprint Backlog) does not change, the rest of the Product Backlog keeps changing.
The Sprint Backlog consists of Product Backlog items selected for the Sprint and a plan for delivering these items. Usually, it consists of tasks, which are the breakdown of Product Backlog items.The Sprint Backlog is the work that Team will do to turn selected Product Backlog items into a Done increment.
The Sprint Backlog is created during the Sprint Planning meeting.
The Sprint Backlog reflects the plan the Team has created for the Sprint. Essentially, the Team manages the Sprint Backlog.
All the work that the Team has planned to carry out in the Sprint is put on the Sprint Backlog.
User Story is a format to define requirements. It is one of the techniques to define requirements on the Product Backlog.
The Product Owner define the product vision. She may define the User Stories, or help the team create the User Stories.
At the beginning, the User Stories are typically large, very big, sometimes referred to as epics. The Team and Product Owner work together to break these large User Stories down into smaller ones. They aim to break the stories so that the Team is able to take multiple User Stories in every Sprint.
The Product Backlog is a living document that is updated continuously. It contains all the requirements, functional and non-functional. After a while, it tends to become messy. It needs regular upkeep, or grooming. The team and the Product Owner work together to get a better understanding of the Product Backlog Items for next 2-3 Sprints. They break smaller item down, refine and define items. The Product Owner may change the order of the Product Backlog. As a result, the items at the top of the Product Backlog are ready to be taken into Sprint Planning
The Product Backlog is groomed during the Sprint, but of course, the grooming effects the Product Backlog for next 2-3 Sprints, not the current Sprint.
The Team and the Product Owner work together to groom the Product Backlog
The recommended length of a Sprint is 1-4 weeks. If the Sprints are longer than a month, the business and technology risk becomes big and usually leads to waste and missed opportunities. This reduces agility.
The team self organizes to work on the items, User Stories or other form of requirements. They turn these requirements into an increment.
The next one starts. Every Sprint starts with a Sprint Planning meeting and ends with the Retrospective meeting. After this, the Team kicks off the next Spring with the Sprint Planning meeting.
Yes, but not the length of the ongoing Sprint. You can change the length of upcoming Sprints, if needed.
The whole Scrum Team i.e. the Product Owner, the Scrum Master and the Team. They may invite any stakeholders, if needed.
Every Sprint starts with a Sprint Planning meeting. The Team works with the Product Owner to plan the work for the upcoming Sprint. They collaborate to help the Team select items (requirements) from the Product Backlog for the coming Sprint. The Scrum Master facilitates the meeting. It is a time-boxed meeting.
The Sprint Backlog. It defines which items the Team will work on and usually a breakdown of these items into tasks.
Every Sprint. Every Sprint starts with a Sprint Planning meeting. No exceptions.
At the end of the Sprint, the Team gets together with the Product Owner and stakeholders for the Sprint Review. They work together to see what was done during the Sprint and update the Product Backlog for the future work. It is a time-boxed meeting. The Scrum Master facilitates this meeting.
The whole Scrum Team i.e. the Product Owner, the Scrum Master and the Team. They usually invite stakeholders and other people interested in the progress of this project.
An updated Product Backlog. The Scrum Team removes the completed items and puts back any incomplete items to the Product Backlog.
This is the last meeting in the Sprint. The Team, the Product Owner and the Scrum Master work together to reflect on the previous Sprint i.e. what went well during the Sprint, what didn’t go so well and what can they do to improve? Retrospective provides an opportunity for continuous improvement.
The whole Scrum Team i.e. the Product Owner, the Scrum Master and the Team. No external stakeholders.
The Scrum Team selects a few improvements ideas it would implement during the next Sprint
Every Sprint. Every Sprint end with a Retrospective meeting. No exceptions.
Sprint Burndown reflects remaining work in a Sprint across time.
The data, estimates of remaining work, come from the Team. The Scrum Master may update the burndown chart. Many tools (even Excel spreadsheets) draw these charts given that the Team updates the remaining work and tasks.
Increment is the work that the Team produces during the Sprint. The aim to get a potentially shippable increment every Sprint.
Product Owner may release the increment at the end of every Sprint, or gather a few Sprints worth of work before releasing that.
It is the set of tasks (piece of work) the Team needs to carry out to ensure that they increment is shippable i.e. ready to go to the market. It defines ready to ship.
The Team and the Product Owner work together to define the Done definition.
The Team and the Product Owner update the Definition of Done, on need basis. But they don’t change the Done definition for the ongoing Sprint.

Organizations (and often customers) need to know how much a piece of functionality cost, how long would it take and what can they expect to get? This project planning but at a smaller level, release level. A release may consist of several Sprints.

The Scrum Team works together to plan the release. They discuss the requirements (part of the Product Backlog), estimates, resource requirements and other relevant issues during release planning meeting.

The Scrum Team. They may invite stakeholders or other Teams they are working with.
Release burndown is the work remaining across time (Sprints) in the release. Sometimes it is referred to as Product Backlog burndown.
The items (User Stories) come from the Product Owner and the Team. The Team estimates the work remaining. The Scrum Master may update the burndown chart. Many tools (even Excel spreadsheets) draw these charts given that the Team updates the estimates
The Team only finds out completed work and thus the amount of work remaining at the end of each Sprint. So the release burndown is updated once a Sprint.
how can we help you?

Contact us at the BTMG USA office nearest to you or submit a business inquiry online.

BTMG USA provided single sign on solutions to help us manage our scattered applications in one place with ease.

Debbie Kübel-Sorger
Chairman, Condor Airlines

Looking for a First-Class Technology Partner?